Présentation de JupyterLab

Le 06/03/2018, une demi-journée de présentation des outils du projet Jupyter a été organisée conjointement par les étudiants et une équipe d’ingénieurs et d’enseignant-chercheurs de l’X. Antoine, David et Philippe y ont participé.
Elle était bien organisée, et faisait appel à des développeurs du noyau mais aussi des utilisateurs.
Le matériel est accessible, et une instance Jupyter a été démarrée au LAL, Adrien R. peut y donner accès.

Pour information, Paris-Sud travaille sur un JupyterHub pour l’Université. Un noyau Spark (Scala) est envisagé.
Pour rappel, le noyau Xeus pour C++ a été développé dans l’Université, par Loic Gouarin, et est déjà utilisé à des fins pédagogiques (cf. café LoOPS sur Xeus).

Une session hackathon est organisée ces deux prochaines journées à l’Université.

Formation Symfony

Symfony est le framwork le plus répandu pour développer des applications web dans le monde PHP.
Les développeurs Symfony sont très demandés.
Sur le même créneau, le principal concurrent est le framework Python Django.

Au LAL, la base des applications web se basaient généralement sur PHP mais aussi FileMaker et Perl. Cette base a été progressivement refondue sur une base unique PHP/MySQL. Le choix du framework Symfony était donc évident dans ce contexte.
Le framework Django est aussi utilisé au LAL pour le monde python.

Depuis 2011, Symfony est utilisé par Justine et Serge pour développer les nouvelles applications pour l’administration et certaines demandes provenant des expériences.
Ils se sont formés avec les didacticiels gratuits qui existaient déjà à l’époque (après avoir raté une première formation IN2P3 à Aussois en 2008).
L’offre des formations gratuites en français est maintenant bien fournie (openclassrooms.com, mooc-francophone.com) mais ne concerne que les versions 2 et 3 de Symfony.
Une formation CNRS à Symfony 4 se déroulera du 4 au 8 juin à Marseille.

Le formulaire de pré-inscription est disponible.
Les informations sont disponibles.

Distribution d’un format de donnée FITS pour le calcul réparti

Un travail a lieu avec Julien et Christian au SI, et Stéphane, un physicien, pour traiter les données d’astrophysique à l’aide d’outils du domaine "Big Data".
L’idée est de distribuer les données pour pouvoir les traiter avec Spark, autour duquel s’est déroulé une formation en début d’année.
Un connecteur SparkFITS a été développé.
La spécificité est que Spark est beaucoup utilisé pour des données textuelles peu structurées (JSON, CSV, logs…), alors que le format FITS est très structuré.
Spark est principalement écrit en Scala. Son utilisation est donc plus intuitive depuis ce langage (bien que d’autres passerelles existent), et il est préférable de passer par Scala pour étendre l’implémentation.

Une bibliothèque FITS a donc été développée en Scala, ainsi qu’un connecteur Spark pour distribuer les données.
Ce dernier découpe un fichier FITS lu par la bibliothèque pour l’envoyer à différentes machines qui feront le calcul. Le format d’entrée-sortie du format FITS est actuellement implémenté en C dans CFITSIO. La lecture-écriture y est séquentielle et en accès direct, il n’est pas pensé pour avoir plusieurs pointeurs d’accès aux données sur le même fichier.
La bibliothèque a été développée avec à l’esprit de permettre un usage facile à une personne sachant utiliser les interfaces Spark habituelles.

Les essais actuels de performances montrent qu’un téraoctet de données ont pu être réparties et traitées au LAL, avec un total de 200 Go de RAM disponible (100 coeurs à 2 Go de RAM).
Spark permet en effet de gérer facilement une quantité de données supérieure à la capacité de la mémoire vive de l’hôte.
Les données sont découpées aléatoirement, mais réparties autant que possible de manière proches afin de faciliter les échanges si besoin.
Les données sont d’abord déposées sur le système de fichier, puis découpées de manière indépendantes.
L’envoi des données peut se faire en flux, et elles peuvent alors être découpées et calculées au fur et à mesure, ou être disponibles sur le système de fichier.
Par exemple, dans le cas d’un calcul de matrice, il faut une description de la structure de données qui permette d’appliquer le calcul sur chaque morceau de cette matrice, même si le flux arrivant est au milieu d’une ligne.
Il est possible de découper les blocs de données de manière fainéante, au fil de leur arrivée, mais cela nécessite que la structure des données soit adaptée à cette façon de traiter les données.

Les prochaines étapes sont de contacter l’autre laboratoire de l’IN2P3 qui travaille sur ces mêmes données, puis une présentation en conférence est prévue dans les prochains mois. Un exemple d’application immédiat est LSST, qui traite 15 To/jour (mais cela peut se ramener à 0,5 à 1To/jour réellement après nettoyage et réduction des données): le logiciel actuellement utilisé n’est pas suffisant pour gérer cette quantité de données.

Avantages du développement en langage fonctionnel

La bibliothèque cfitsio a été en partir réécrite en scala, pour être utilisée en calcul réparti. Cela représente un mois de travail et 1000 lignes, mais comme les langages fonctionnels sont plus expressifs que les langages impératifs, cela correspond à un nombre de lignes bien supérieur en langage impératif.

Julien en profite pour recommander la formation Scala car elle est très bien faite et lui a été très utile. Christian indique que les interfaces de développement sont très bien faites en Spark aussi. Le mariage entre orienté objet et fonctionnel ajoute la possibilité d’héritage, qui est efficace :

• les données FITS étant en N dimensions (pas forcément 2D), la méthode de découpage en lui-même a pris plusieurs jours ;
• le fait que Spark soit libre (licence Apache) a fait gagner 15 ans de développement. Cela encourage les entreprises à participer au développement de manière visiblement efficace. Exemple : SOLEIL discutait par exemple hier avec Quant, qui travaille sur le développement de jupyter, pour adapter jupyter à leur besoins pour les acquisitions des expériences ;
• Jupyter peut être interfacé avec Scala pour être utilisé avec matplotlib ;
• on peut interfacer du Python dans du Scala grâce à JEP, l’équivalent de JNI en Java.

PSPA

Un prestataire extérieur a été choisi pour définir l’ergonomie de l’interface de PSPA, et proposer une solution.
Cela obligera à reprendre les interfaces internes comme publique.
Le bus pourra se faire en Flask, mais l’outil n’est pas encore défini.
Marika, l’experte machine, a rencontré l’ergonome. D’autres entrevues sont prévues avec des utilisateurs (Laurent Nadolski de SOLEIL, un utilisateur de l’IPNO…).
3 mois de travail est prévu, l’échéance est un peu plus longue pour découpler l’interface du moteur, ce qui nécessite de refaire du développement.

SVOM

Marc porte du code Python 2 en Python 3. Une première partie du travail consiste à nettoyer le code grâce à auto pep8 et pylint. Une seconde étape consistera au portage de python 2 à 3 lui-même, avec des outils comme « six », « modernize » et « 2to3″…
Le travail avec le CNES va se baser sur la méthode de gestion de projet agile Scrum.
Antoine demande quelle solutions existent pour un calendrier à distance. Philippe a eu un retour de Valérie pour éviter le calendrier de owncloud.lal.in2p3.fr et préférer celui de zimbra, car le premier est complexe à gérer: les noms des utilisateurs avec lequel on partage le calendrier ne s’affichent pas clairement.
D’autres outils déjà évoqués donnent accès à ce genre d’outils (Philippe indique https://framaboard.org/ qui est une instance kanboard, Antoine indique que Trello aurait des modules similaires).