Stage de Malek El Ouerghi - ENSIIE Strasbourg - [22/05/17 au 28/07/17]

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é

Sujet

• Proposition de stage

Stage (Mai - juillet 2017)

Mai

• 22:
  • Arrivée
  • Visite des locaux de l'Observatoire
  • Lecture des Wiki & des rapports des stagiaires précédents sur le sujet (Arnaud Steinmetz, Pierre Lespingal et Nicolas Adam)
  • Imprgénation du travail déjà réalisé
  • Installation de l'IDE WebStorm et de Oh-My-Zsh
  • Conférence sur leSkyMapper par Christian Wolf
• 23:
  • Création compte Gitlab et ajout de la clé SSH
  • Début de familiarisation avec Node.js (je ne l'avais jamais utilisé auparavant => nécéssité d'approfondir mes connaissances en JavaScript)
• 24:
  • Fin des recherches sur le JavaScript
  • Réunion avec André Schaaf et Pierre Barjon pour une présentation des services de l'Observatoires et de ses applications
  • Clarification sur le sujet du stage :
    • Ne pas reprendre le travail de Nicolas Adam et seulement l'améliorer
    • Réfléchir à une nouvelle piste
    • Comment transférer les données depuis le serveur, comment gérer l'indexation, éventuellement réfléchir à un changement de structure de données (changer l'octree pour autre chose)
    • Ne pas toucher à la partie cliente (précédemment faite par Arnaud Steinmets et Pierre Lespingal)
    • Faire des recherches sur un moyen efficace de transfert et de manipulation de données
    • Implémenter un serveur à la main ? Cela donnerait plus de contrôle sur le fonctionnement de celui-ci plutôt que d'employer Node.js
    • Réfléchir au stockage des donnée
• 25 : Jour férié

• 26 : Pont de l'Ascencion
• 29 :
  • Clonage du git et début de compréhension du code de Nicolas Adam et des autes stagiaires
  • Rapide tutos openclassrooms sur node.js et MongoDB
  • Recherche sur les octrees et sur la manière de les stocker :
    • https://geidav.wordpress.com/2014/07/18/advanced-octrees-1-preliminaries-insertion-strategies-and-max-tree-depth/
    • Octree-based_indexing_for_3D_pointclouds.pdf
  • Test de l'application serveur et cliente => l'application serveur n'a aucune donnée en BDD il faut que je trouve le moyen de la peupler
  • Après comparaison, il semblerait que node.js reste un serveur plutôt rapide comparé aux autres, et je pense que l'idée de coder moi-même un serveur manuellement serait plus une perte de temps qu'autre chose
  • À voir si l'on reste sur une base de données Mongo : il existe Oracle Spatial, qui permet de gérer les structures relatées à la 3D, et selon le PDF plus haut, les performances seraient plutôt correctes. À tester.
• 30 :
  • Correction de problèmes présents dans les fichiers XML de configuration de projets WebStorm qui venaient probalbement des merges précédents. Le projet est chargé normalement désormais.
  • Création d'un gitignore pour éviter de surcharger le dépot avec la doc, les paquets node et les fichiers de configuration de l'IDE
  • Tests avec le code serveur de Nicolas sur ma machine en local : je n'arrive pas à importer correctement les données dans l'appli WebGL (pourtant elles sont bien stockées dans MongoDB) => À revoir demain.
  • J'essaie de comprendre le code de Nicolas pour voir ce qu'il a fait et surtout comment il l'a fait, pour éviter que je fasse la même chose
  • Lecture d'un article plutôt intéressant concernant les octrees (et nottamenent leurs usages dans les jeux vidéos) : https://www.gamedev.net/resources/_/technical/game-programming/introduction-to-octrees-r3529
  • Je crée des branches différents sur le git lorsque je fais des tests sur des features, pour éviter de toucher le code "sain" sur le master
  • Installation de RoboMongo pour facilement voir les données dans la BDD sans passer par la ligne de commande

• 31:

  • Soutenance de stage par Cédric Vogel, stage qui portait sur la réalisation de template audio & vidéos pour la création de tuto

  • Suite de la lecture de l'article sur les octrees
  • Recherches sur le web conernant d'autres structures de données pouvant remplacer les octrees:
    • nanocubes : il semblerait que la piste ait déjà été écartée l'an dernier par Nicolas Adam, je ne vais donc pas rester sur cette idée
    • J'ai du mal à trouver d'autres structures que les octrees : il semblerait que ce soit cette structure là qui soit priviligiée dans 90% des cas de traitement 3D
    • Il y'a aussi d'autres formes d'arbres que les octrees, mais visible leurs performances seraient moins grandes que les octrees ( cf. le PDF uploadé précédemment)
    • Je pense rester sur des octrees tout de même
  • J'essaie de comprendre le code de Nicolas mais pour le moment c'est assez confus : j'ai vraiment du mal à cerner le fonctionnement de certaines parties de l'appli serveur.
  • Il faudrait que j'aie accès au vrai jeu de données (celles stockées sur le serveur en LAN) : André Schaaf m'a dit qu'il me donnerait un accès prochainement, pour l'instant je n'arrive pas à faire fonctionner l'appli cliente avec des données stockées sur l'appli serveur tournant en local

Juin

• 1:
  • J'ai eu les accès aux serveurs contenant les données
  • Problèmes lors des tests avec l'appli :
    • Le jeu de points n'apparait pas dans l'affichage 3D (la console JS indique une erreur comme quoi les objets reçus par le serveur sont nuls)
    • Je pense que j'utilise mal l'application serveur, je demanderai plus d'infos à ce sujet la, car à chaque requête d'octant elle envoie un arbre de longueur 0
  • J'ai terminé la lecture de l'article sur les octrees dans les jeux vidéos, je pense qu'il contient pas mal d'infos susceptibles de m'aider dans mon travail
• 2:
  • J'ai continué le "déchiffrage" du code de l'application serveur : je pense qu'il y a un problème au niveau de la construction de la représentation de l'arbre
  • Idée : utiliser des clusters pour le côté base de données avec les deux serveurs disponibles:
    • Il y aurait des possibilités de gain de performances
    • On pourrait stocker un plus gros volume de données
    • Ça a l'air difficile à mettre en place cela dit, surtout avec un jeu de données déjà chargé côté serveur, cela impliquerait d'à nouveau charger les données
    • Il faut faire attention quant au choix de la clé de sharding utilisée pour séparer les données, car il semblerait qu'elle ait un grand impact sur les performances d'accès et d'insertion des données
    • Ça a l'air faisable avec MongoDB (je n'ai pas regardé pour les autres SGBD à vrai dire)
  • Autre piste pour la base de données : utiliser PostgreSQL avec son GIST pour ordonner l'octree en base de données, à tester.
  • On écarte l'éventuelle piste soulevée d'Oracle Spatial car il est payant
  • Je pense que si je mets en place l'un des deux systèmes au-dessus, il va falloir que je reparte quasiment de zéro au niveau du serveur, évidemment il y aura des fonctionnalités qui recouperont avec l'application réalisée par Nicolas Adam; à voir

• 5: Pentecôte, férié
• 6 :
  
  • Réunion avec André Schaaff pour discuter des pistes et mettre en place les problématiques du stage
    • Revoir l'indexation des points
    • Éventuellement utiliser un autre système de base de donnée que MongoDB (par ex: Postgresql si j'arrive à exploiter correctement GiST)
    • Rebosser l'application serveur
    • Voir comment afficher le voisinage + stockage des index des voisins d'un octant dans la bdd pour y accèder plus vite (déterminer les voisins d'un cube au moment de la construction au lieu du temps réel)
    • Afficher que les cubes dans le camp de vision + ceux à la périphérie ?
    • Utiliser un RAMdisk pour l'arborescence de l'octree dans le file system
    • Peut-être étaler la charge de MongoDB sur les deux servers
    • Passer l'application serveur écrite en NodeJS en mmultithread (accélérer le traitement des données)
    • Voir comment gérer les données dégradées d'un octant
    • Utiliser un autre arbre que l'Octree
    • Élaborer une stratégie pour diviser un octant en 8 (par ex avec un seuil sur le nombre de points par cube)
  • Lecture d'un site web pour l'utilisation de GiST (https://www.postgresql.org/docs/current/static/gist-intro.html)
  • Lecture d'un article expliquant l'indexation GiST (http://gist.cs.berkeley.edu/)
  • Lecture du code de Nicolas pour comprendre comment fonctionne l'application serveur
• 7 :
  • Fin de la lecture du second article d'hier : je n'ai pas l'impression que l'on puisse en tirer quelquechose : il date de 1999 et il est très théorique et peu facilement pratiquable
  • Le page de Postgres est beaucoup plus explicite à ce sujet là : c'est un "tutoriel" sur l'utilisation du GiST
  • Postgres intègre un type "cube" (qui peut être de dimension quelconque) : à voir si il est intéressant à utiliser pour l'octree
• 13 :
  • Lecture de la doc et de tutoriel sur l'utilisation de Postgis
  • L'utilisation du GiST serait apparement plus avantageuse d'un point de vue performances qu'un arbre classique (qui est utilisé par défaut dans les SGBD SQL) : à comparer avec Mongo
  • Installation de Postgresql et de l'extension Pointcloud (qui ajoute les nuages de points aux types déjà présents dans Postgres)
  • Création d'un script python de test pour voir comment fonctionne Postgis (en chargant les points depuis un fichier trian)

• 14 :

  • J'ai continué mon script Python d'hier

  • J'ai fouillé la documentation de l'extension Pointcloud pour essayer de voir comment mettre en place la base de données : il semblerait que ça soit assez compliqué à utiliser, je me repenche dessus demain
  • Il faut créer un "schéma" en XML à insérer dans la base de données avant de pouvoir y insérer des données issues des simulations. Le schéma permet d'indiquer au SGBD comment lire les données et les interpréter, car elles ne sont pas stockées sous forme de chaine de caractères ou d'entiers/flottants, mais plutôt sous forme "binaire" (selon la doc, cela permet de récupérer les informations nécessaires lors d'une requête plus rapidement)

• 15 :

  • Création du fichier XML pour le schéma terminé
  • Tests d'insertions de points depuis un fichier trian d'environ 4000 points : l'insertion se fait en une minute, et la lecture se fait en 20 ms
  • Je vais essayer de voir comment réduire le temps d'insertion dans la base
  • Il faut encore que je définisse la structure de la base pour gérer les octrees
    • Je pense que je vais devoir réécrire totalement l'application serveur, car au final, vu l'ampleur des modifications dans la structure de données, ce serait fastidieux de modifier l'application déjà éxistente
    • Je ne sais pas encore si je reste sur du Nodejs ou pas
    • Incorporer l'asynchrone et le multi-thread
  • Je vais essayer de faire un programme Python complet pour la phase de test une fois que j'aurais correctement créé la base de données
  • Pré-soutenances des DUT toute la matinée

• 16 :

  • Fouille de la documentation des libraires asynchrones de Python
  • Modification du script de lecture des fichiers en conséquences : on gagne en perf, et on peut commencer l'insertion sans avoir à lire le fichier intégralement
  • Au vu de la compléxité de l'utilisation de l'asynchrone en Python (j'ai assez de mal pour le moment même si cela fonctionne), je pense retourner sur le JavaScript la semaine prochaine
  • Début de mise en place de la base de données PostgreSQL

• 19 :

  • Création de la table PostgreSQL acceuillant les octrees :
    • id en clé primaire
    • Code de morton avec condition d'unicité
    • Nuage de points (Pcpatch)
    • Tableau de codes de morton pour indiquer les voisins de l'octant
  • Concernant le code de Morton pour identifier l'octant :
    • J'avais pensé stocker en BDD directement des données binaires pour les manipuler et les lires plus facilement qu'une chaîne de caractères mais cela n'est pas possible
    • Pour l'instant, il est stocké avec le type bytea qui est un ensemble d'octets que l'on peut lire et modifier avec des Escapes et des valeurs hexadécimales
  • Peut-être migrer directement les données depuis MongoDB vers Postgres sans passer par la lecture de fichiers ?

• 21 :

  • Repas du Solstice
  • Écriture d'un script Python pour récupérer les points stockés dans MongoDB en vue de les injecter dans Postgres, tout ça toujours en asynchrone avec la libraire Motor (basée sur asyncio)
  • On est sur 80s de lecture depuis MongoDB pour récupérer environ 4 millions de points
  • Demain je me lance dans l'écriture des scripts pour générer l'octree et stocker les points correctement dans PostgreSQL
  • Problématique du corde de Morton d'un octant : j'ai finalement opté pour le type varying bit (qui est une bit string enfait) car elle présentait des opérations binaires assez intéressantes, qui pourraient m'être utiles par la suite
  • Il faut que je fasse le changement dans le fichier de driver de PostgreSQL pour utiliser l'asynchrone au vu des volumes de données manipulées...

• 22 :

  • Finalisation du script Python qui "communique" avec PostgreSQL, avec cette fois la mise en place de l'asynchrone
  • Demain, je me mets à la création et la gestion de l'octree pour pouvoir démarer les premiers tests de l'appli
  • Réunion avec André Schaaff pour discuter de l'état de la suite du projet :
    • Utiliser un cube englobant la caméra (le client enverrait au serveur la position actuelle de la caméra au lieu de demander les octrees directement)
    • Demander uniquement les points qui n'ont pas été déjà chargés
    • Il va falloir probablement modifier la partie communication avec le serveur du client
    • Faire des tests avec PostgreSQL pour voir si il supporte bien le passage à l'échelle. Altérnatives : Greenplum ou MongoDB
    • Liberté du langage, je pense rester en Python vu que je maitrise mieux que le JavaScript (pour l'application serveur)
  • Idée : Utiliser le cube englobant comme dit plus haut, mais combiné à l'octree, faire des intersections avec les octants de l'octree pour savoir lesquels charger

• 23 :

  • Implémentation de l'octree en Python
  • Début de tests:
    • Avec des points chargés depuis un fichier : insertion sans aucun soucis dans l'arbre
    • Avec les 4 millions de points de MongoDB : plantage que je n'ai pas encore résolu, je m'y repenche Lundi
  • Passage de Python 3.6 à PyPy 3.5 pour gagner en performances : j'ai du modifier a la mano un package (aiopg, le driver asynchrone pour PostgreSQL) pour qu'il fonctionne avec PyPy ( NE PAS OUBLIER DE LE FAIRE AU MOMENT DU 'DEPLOIEMENT' ) => Peut-être que je ferai un "fork" du package avec les modifications pour éviter de le refaire à chaque fois

• 26 - 27 :

  • Correction du problème de la semaine dernière : juste une typo lors de la création des sous-cubes qui faisait planter l'environnement

  • Création de la classe Cube : elle me servira à déterminer les voisins d'un octant et par la suite, mettre en oeuvre l'idée de l'intersection du cube englobant avec l'octree
  • Méthodes pour déterminer les voisins :
    • Évaluer quels faces sont confondues (ou inclues, dans le cadre d'un voisin plus petit ou plus grand)
    • Évaluer les distances entre les centres et voir pour quels cubes on a : distance entre les deux centres = demi coté du premier cube + demi coté du second
    • Pour trouver les voisins qui n'ont pas de face communes (ceux situés sur les diagonales) : comme au dessus, sauf qu'on travaille sur les diagonales des cubes
  • Librairie intéressante pour stocker l'octree sur le disque sans avoir à le reconstruire à chaque fois : Pickle, elle permet de représenter un objet Python sous forme binaire dans un fichier

• 28 :

  • Création de la fonction pour trouver le voisinage d'un octant :
    • Au début, je résonnais sur la distance euclidienne mais je me suis vite rendu comtpe que ça ne prennait pas les voisins qui étaient de taille plus petites (il aurait fallu faire une projection..)
    • Pierre Barjon m'a conseillé d'utiliser la distance infinie : elle est beaucoup plus pratique dans ce cas la, car les voisins se résument à ceux qui se trouvent sur les extrémités du cube défini par la norme infinie
  • Lecture de la doc EventHandler : je pense m'en servir pour mettre à jour la base de donnée lors de la modification de l'arbre (ajout d'un octant ou division d'un octant..)
  • Début de l'écriture serveur avec la librairie aiohttp

• 29 :

  • Abandon de la norme infinie pour déterminer les voisins : inutile
  • À la place, je raisonne les sur les sommets des cubes en comparent leur coordonnées
  • Tests rapides de la fonction, elle a l'air de fonctionner parfaitement, je continuerai les test demain avant le point avec André Schaaff
  • Il faudra que je pense à netttoyer le code pour enlever toutes les lignes inutiles

• 30 :

  • Code nettoyé
  • Tests plus approfondis de la fonction qui trouve les voisins : elle fonctionne
  • Recherche sur les EventHandler en Python : quelques tests pour cerner le fonctionnement
  • Transfert des scripts JS pour lire les fichiers de données (trian, part, xyz) vers le Python : Trian : OK, Part : en cours, XYZ : pas entamé
  • Discussion avec André Schaaff de l'avancé du projet et du futur : je dois tester si PostgreSQL tient la charge avec les 4 millions de points qui sont actuellement présents dans Mongo pour voir si c'est viable
  • Il faudra mettre le code sur le Gitlab

Juillet

• 3 - 4 :
  • Scripts pour charger les fichiers part binaires : OK
  • Ajout d'une fonction prenant en paramètre un chemin, et qui charge tout les fichiers si c'est un dossier ou un le fichier si le chemin pointe vers un fichier
  • Problème : certains fichiers ne sont pas lus : je me repenche dessus demain, et si je n'arrive pas à corriger, tant pis je repasserai sur la gestion de l'arbre
  • Optimisation de l'utilisation de l'async en Python
  • Restructuration du projet
  • Nettoyage du code

• 5 :

  • Lecture fichiers : OK
  • C'était juste un problème de taille au niveau de stdout lorsque je demandais l'affichage, vu la taille des données (plusieurs centaines de Mégaoctets)
  • Début d'écriture du script de gestion de la base de donnée : j'ai réussi à mettre en place l'EventHandler (qui appellera les fonctions de mise à jour de la base de donnée lorsque la structure de l'arbre est modifiée)
  • Réarrangement du code de gestion de la base de données PostgreSQL (j'ai modifié les méthodes afin que l'on ait besoin d'appeller qu'une seule méthode depuis l'extérieur peu importe l'action demandée, SELECT, UPDATE, DELETE ou INSERT)
  • J'ai passé les autres méthodes du driver PostgreSQL async en privée afin d'éviter une mauvaise utilisation par la suite
  • De même pour la lecture de fichier
  • Je vais me repencher sur Pickle (car l'arbre finira par être trop gros pour être stocké en RAM) ou alors faire en sorte que l'on stocke la structure de l'arbre sans les points qui lui sont rattachés

• 6 :

  • Progression de la gestion de la base de données : On peut désormais ( normalement) insérer des octants dedans
  • Il faut que je refasse le gestionnaire des requêtes SQL pour passer les paramètres de la requête au driver PostgreSQL plutôt que de formater la chaine de caractère avec Python avant de l'executer (faille de sécurité)
  • Pour l'instant, les interrogations SQL pour obtenir des octants sont rapides : quelques ms pour récuperer 2 millions de points (sans le traitement Python qu'il y a derrière)

• 7 :

  • L'insertion d'octant me produit une erreur SQL que je n'arrive pas à résoudre...
  • Modification du gestionnaire de requêtes SQL pour combler la faille de sécurité évoquée hier
  • Je pense que l'erreur d'insertion vient de cette modification
  • Il faut à tout prix résoudre ce problème car cela m'empêche d'avancer

• 10 - 11 :

  • Problème résolu : on peut maintenant insérer dans la base de données des octants
  • Création d'un gestionnaire d'évement : j'ai repris une librairie que j'avais trouvé précedemment sur le net en y ajoutant l'asynchrone pour pouvoir l'intégrer dans le projet
  • Ajout de l'event à la structure de l'octree : il faut juste que je trouve un moyen efficace de le déclencher au bon moment
  • Après cela, je pourrai commencer à travailler sur la transmission serveur-client et comment communiquer entre les deux
  • Il faudra probablement que je modifie la partie cliente pour la greffer au serveur
  • J'ai trouvé une lib intéressente pour créer une API JSON (elle n'a pas besoin d'être totalement REST) qui a l'air plus performante et robuste que les autres disponibles : http://pycnic.nullism.com/
    
  • Pas besoin d'un gros framework web (de type MVC comme Ruby on Rails ou du genre) pour le peu de requêtes qui doivent être traitées

• 12 :

  • Test sur l'ajout d'octants avec les 4 millions de points : crash de Python à cause de la récursivité + saturation de la boucle évenementielle d'asyncio
  • Je pense que l'utilisation du multi-threading résoudrait le problème, mais au vu de l'organisation actuelle du code, cela risque d'être compliqué à mettre en place sans tout modifier
  • L'async ralentit énormement l'insertion : bizarrement, sans le lien avec la BDD, l'insertion prend seulement 40 secondes dans la RAM alors qu'avec la base de données, on ralentit énormement (seulement une quarantaine de points par seconde)
  • Il faudra peut-être passer à une insertion itérative plutôt que récursive vu que le récursif et le Python ne font pas bon ménage

• 13 :

  • Résolution du problème de récursivité
  • J'ai changé d'approche pour l'insertion de la base de données : je stocke dans une liste (après avoir créé l'arbre) les opérations à effectuer en base de données pour synchroniser la base de donnée
  • J'execute ces modifications dans un thread différent, pour ne pas surcharger le thread principal mais pour l'instant il y a un problème que je n'arrive pas à résoudre
  • Je me repenche dessus lundi (ça devrait fonctionner)

• 17:

  • Insertion de l'octree dans le base de données (chaque feuille comporte un id, les points, le cube délimitant l'octant, le code de Morton ainsi que les codes de Morton de ses voisins): OK
  • Début de l'écriture de l'application web (finalement j'utilise Sanic au lieu de Pycnic pour cause d'un non fonctionnement d'un composant essentiel (le codeur/decodeur JSON) dans la librairie..)
  • Installation du serveur web WSGI Gunicorn
  • Installation de Postman pour tester l'API rapidement à l'aide des requêtes JSON
  • La selection d'un esemble de points (ceux qui sont compris dans un cube que l'on donne en paramètre) se fait en 100 ms (j'ai testé avec 4 millions de points, donc ça devrait être encore plus rapide pour un plus petit champ de vision)
  • Passage de l'insertion des points dans un Octree dans un thread séparé, pour profiter au maximum du temps CPU
  • De même pour le calcul des voisins pour toutes les feuilles de l'arbre
  • Il faudra que je mette en place Pickle pour éviter de créer l'octree à chaque démarrage de l'application
  • Il faut aussi que je m'occupe de vider les points de l'octree en RAM une fois qu'ils sont stockés en base de données, sinon on va avoir un manque de RAM quand on passera aux milliards de points
  • J'ai commencé à regarder le code côté client pour voir comment je peux le modifier pour le faire fonctionner avec mon serveur, pour l'instant je n'y comprends pas grand chose et je ne suis pas sûr du fonctionnement de l'appli..

• 18 :

  • Mise en place du multithreading pour l'insertion en base de données : beaucoup plus rapide ! On passe de 25 min pour l'insertion initale + les voisins à seulement 8-9 min sur un PC avec 4 coeurs
  • Je pense avoir approximativement compris le fonctionnement du client pour les requêtes : il y a un problème car le client demande directement les octants au serveur et je n'utilise pas la même structure d'octree que le client
  • Mise en place du Pickler pour libérer la RAM en cas d'octree trop grand
  • Installation de Sanic_compress pour compresser les réponses JSON
  • Nettoyage du code (en particulier les scripts gérant PostgreSQL)

• 19 - 20 :

  • J'ai laissé tomber les requêtes JSON car trop long à encoder/décoder
  • Je pense utiliser des websockets, car comme ça on évite la surcouche du protocole HTTP et la nature de celui-ci (sans état):
    • Le serveur peut envoyer des données quelconques
    • On garde côté serveur facilement les états actuel et précédents du client (sa position dans la simulation)
    • Avec cette position, on cherche les points dans PostgreSQL que l'on doit envoyer au client pour qu'il les affiche
    • On peut ainsi mettre en place un système différence (par exemple avec un descripteur qui est envoyé avec les points au client pour qu'il sache quels points garder lorsqu'il se déplace)
    • C'est aussi beaucoup plus simple dans notre cas, puisque l'on cherche à avoir une bonne interactivité de l'appli, que de passer par le protocole HTTP
    • Avec quelques tests rapides, on divise par 4-5 le temps entre la requête client et la réponse du serveur avec les bonnes données
  • Je me suis rendu compte d'un gros problème dans la base de données:
    • Le schéma de l'extension Pointcloud (qui est un schema en XML qui décrit comment stocket et encoder les coordonées des points) indiquait de stocker les coordonées dans des Int32 (plus simple à compresser que les float)
    • ça ne pose pas problème car les float (normaux, pas les double) sont encodés en 32 bits donc on ne perd rien
    • En revance, lorsque l'on passe sur des très grands nombres : l'extension Pointcloud effectuait automatiquement une troncature des coordonées lorsque la taille de celle-ci dépassait l'encodage
    • Corrigé, passé en int64 (équivalent aux double)
  • Amélioration de l'appli web, suppression de la compression puisque l'on ne passe plus par du JSON mais par un protocole TCP classique
  • Correction de divers bug et amélioration du code
  • Il faut voir comment implémenter les websockets côté client

• 21 :

  • Tranmission par websocket : Ok pour le côté serveur, on peut traiter des données sans problème et y répondre (avec les points)
  • Problème en revanche au niveau des connexions : si deux clients se connectent en même temps, et font des requêtes longues en même temps, la connexion WebSocket plante pour l'un des deux (le dernier à s'être connecté en général)
  • Pour la conversion des données Python (liste de points) en données que l'on peut envoyer (WebSocket se limite à des string ou des bytes) et lire facilement en JavaScript, j'utilise Msgpack : il en existe des versions pour quasiement tout les langages =>
    on encode en Python et on décode en JavaScript sans aucun problème, en gardant la structure de l'objet (en plus c'est performant en comparaison à d'autres solutions).
  • La transmission par WebSocket ne prend que quelques millisecondes pour chargers environ 10k points et quelques secondes pour en charger 4 millions
  • Réunion avec André et Jérôme pour discuter du projet:
    • Je sais maintenant quoi modifier dans la partie client pour faire le lien avec mon serveur
    • Il faut toucher au fichier RequestHandler.js et View.js
    • Il n'y a finalement pas de problème de compatiblité entre le client et le serveur car il n'y a pas besoin de demander un octant en particulier, il suffit juste de donner des données à une fonction qui s'occupe de les ingérer dans la simulation
• 24 :
  • Utilisation et configuration de Gunicorn avec Sanic, configuration complète du serveur : l'appli est prête (quasiement) à être déployée derrière un proxy tel que Nginx
  • Début de l'implémentation des WebSockets côté client pour lier les deux parties:
    • Utilisation des Promises avec l'objet natif WebSocket
    • Fonction permettant de demander des points aux serveurs et de les récupérer
    • Reste à faire : triatement des données reçues, et affichage dans la simulation
    • Aussi, gérer l'interface (boutton de connexion au serveur) + le laisser activé tant que la connexion est active (connexion TCP simple et non HTTP)
    • Discussion avec Jérôme qui m'a donné pas mal d'infos sur la partie cliente pour que je puisse travailler dessus
  • Il faut que je finalise la partie Python manquante (bien gérer tout les scripts et corrigers certains problèmes)

• 25 :

  • Avancement dans l'implémentation côté client
  • La modification du code du client est fastidieuse au vue de la taille de celui-ci
  • Ajout d'une route côté serveur permettant de récupérer les bornes des coordonées des points (requises par le client)
  • Problème avec les Promises : pas sûr d'avoir saisi le fonctionnement

• 26 :

  • Problème des promises résolu : connexion avec le cliente presque complète (il faut juste que je m'occupe du bouton qui lance la connexion)

• 27 :

  • Connexion ok avec le serveur (il faut arranger un peu pourque ça soit plus érgonomique)
  • Problème : lorsque le client demande les bornes au serveur ( (0,2^62) dans mon cas), le deuxième nombre est trop grand: en Python, il est encodé en long, sauf qu'en JS, les long n'existend pas, il n'y a que des doubles, et selon l'encodage des doubles, au dela de 2^53 - 1 on a des arrondis => lorsque qu'on affichait les points, au moment de la divison, cela avait pour effet de mettres tout les points chargés à l'origine du cube, tous tassé au même endroit (j'ai réussi à faire planter le naviguateur en ce moment)
  • Je travaille sur la correction, il va falloir reconstruire la base de données...
  • Concernant le serveur, je remet en forme le code pour qu'il soit clair et utilisable, car jusqu'à maintenant c'était le fouilli
  • Sinon point positif : même si les points éttaient tassés à l'origine, lorsque l'on se déplacait dans le client, les points étaient reçus dynamiquement et l'afficha restait fluide

• 28 :

  • Pré-soutenance de Pierre Barjon
  • Arrangement du code : le serveur se lance avec un fichier, j'ai ajouté une doc d'aide (qui s'affiche lorsque l'on ajoute le flag -h en ligne de commande)
  • Gestion des paramètres : on peut demander à insérer des données dans la base de données soit depuis Mongo soit depuis un ou plusieurs fichiers
  • On peut demander à lancer le serveur web après l'insertion ou sans l'insertion
  • Je me suis rendu compte d'une chose: le fait d'utiliser les thread en Python ne garantissent pas l"utilisation des coeurs du CPU, pour cela il faut utiliser les process. Je me repenche dessus lundi car il y a moyen de nettement améliorer le temps de création de la base de données
  • Création et gestion d'un fichier de configuration en YAML pour gérer les infos de l'appli (nombres de points par feuille, taille de l'arbre etc) qui est chargé au début dans un dictionnaire clé-valeur, que l'on peut modifier en RAM et qui est ensuite enregistré lorsque le programme se termine
  • Re-création de la base de données en prenant en compte les contraites évoquées hier concernant la grandeur des nombres
  • Le problème est toujours le même... les points s'aglutinent à l'origine du cube dans le client : je le corrige lundi

• 31 :

  • L e lien entre l'application cliente et le serveur est ok : l'affichage dynamique fonctionne
  • L'affichage est relativement fluide
    
  • Modification du boutton de connexion pour qu'il déconnecte/connecte selon l'état du lien
  • Modification des champs adresse ip et port du serveur pour qu'ils servent à quelquechose
  • Arrangement du code Python
  • À faire : commenter + gérer le cas des milliards de points + gérer le mode "rotation" du cube
    

Liens

Versions testables

• http://cdsgit.u-strasbg.fr/visu3D/AstroViz3D/tree/malek

Documentation

Travail post stage éventuel

Liste des améliorations à envisager

Bugs connus