Ce système mis en place, le LRI a fait un appel aux laboratoires de Paris-Sud pour explorer les capacités de ce nouveau genre de plate-forme de visualisation et d’interaction homme-machine pour étudier, manipuler leurs données. Fort d’une culture dans la visualisation et les outils d’analyse des données HEP et astro-particules, le LAL a répondu à cet appel afin de voir si des scénarios intéressants pouvaient se dégager pour améliorer la compréhension de nos données en utilisant ce genre d’environnement.

Un premier jet de logiciel a permis d’explorer en 2010 le scénario du « 3D immersif » où on considère tous les écrans « comme un seul » visualisant un partie du détecteur LHCb en 3D avec une navigation dans la scène (c’est le scénario des jeux vidéos !). Cette première étape a permis de se rendre compte de la réactivité du système qui s’est avérée très bonne avec des scènes pas trop chargées. Bien évidemment, le résultat visuel est très impressionnant et donne clairement le goût à la poursuite de l’exploration de ce genre de plate-forme. Mais le scénario 3D-immersif n’est pas forcément le seul scénario intéressant. Par exemple, un autre scénario attractif serait celui du « brainstorming à plusieurs » devant un mur de données : une ou plusieurs personnes « jettent » des représentations de données sur le mur depuis leur ordinateur personnel puis discutent, manipulent ce qui est vu. Mais ce scénario, pour être attractif et vraiment utilisable dans un laboratoire, ne doit pas être trop contraignant pour l’utilisateur, en particulier il ne doit pas induire une instrumentation trop contraignante des personnes. Or, il s’avère que l’année 2010 a vu l’émergence des tablettes et des écrans tactiles qui changent la donne en ce qui concerne le dialogue homme/machine. En particulier cela change la perspective de ce scénario brainstorming ; il est très facile de croire au scénario de plusieurs personnes arrivant chacun avec leur tablette devant un mur d’écrans tout ou partiellement tactiles, envoyant des données « du bout du doigt » sur le mur puis travaillant sur ces données aussi « du bout du doigt » sur ce mur. Ce scénario « à tablette » est celui qu’on explore en ce moment sur le « petit mur » (le murino) du LAL.

Le murino du LAL

Notre « petit mur » est constitué maintenant de 12 écrans non tactiles (3x4) pilotés par quatre « gros » Macs (trois écrans par machine) plus un Mac de contrôle (le maître). Ce matériel a été fourni en 2010 dans le cadre d’un projet ARTS par Apple. Bien que moins impressionnant que le mur du LRI, ce matériel « sur place » offre d’excellentes performances qui permettent d’avancer rapidement sur les logiciels et donc d’explorer divers scénarios. Pour les tablettes, on utilise au quotidien un iPad-1 et un Samsung Galaxy S sous Android-2.2.

Les choix logiciels ; langage, rendu graphique, interface utilisateur :

iOS et Android utilisent tout deux de l’OpenGL « ES » (Embedded System) comme couche de rendu de base. Comme GL-ES existe aussi pour les autres systèmes (MacOSX, Linux, Windows), et donc aussi sur les machines du mur, on a développé un gestionnaire de « graphe de scène » s’appuyant sur GL-ES (inlib/exlib) pouvant afficher indifféremment sur le mur mais aussi sur les tablettes. Pour le langage de programmation, comme C et C++ sont communs à tous ces environnements et si on « croit en l’OO », le C++ s’impose donc comme choix naturel. Un point important dans nos choix est de gérer l’interface utilisateur aussi avec notre graphe de scène basé sur GL-ES. En effet, suivre les choix d’Apple et Google sur les tablettes aurait contraint à ce que chaque élément de l’interface utilisateur (bouton, liste, etc.) aurait du être décrit avec une librairie spécifique et dans un langage spécifique (Objective-C pour iOS et java pour Android), chose qui aurait été difficilement gérable par un homme seul. Ici, même si l’aspect de nos boutons laisse parfois à désirer, la fonctionnalité est là et nous pouvons gérer, avec le même code, nos « smart-devices » et notre murino.

A part le graphique et l’interface utilisateur, une plate-forme de visualisation multi-machines-multi-écrans demande aussi une logique spécifique pour que cela soit vu comme un « tout cohérent ». Pour l’instant nous avons convergé vers une architecture client/serveur avec un programme « chef d’orchestre » tournant sur la machine maître et un programme client par écran sur les « machines mur » (soit treize processus en tout au LAL et 33 pour le mur du LRI). Les clients étant déjà installés sur les « machines mur », le démarrage se fait par un simple shell script sur la machine de contrôle qui démarre le programme maître puis les douze clients par commandes ssh. La communication maître/clients se fait par un protocole dédié implémenté sur de la « socket de base » disponible en standard sur tout les systèmes (y compris iOS et Android). L’« affichage cohérent » est fait par « rendu tuilé » : chaque programme écran gère une partie de la projection d’une même caméra globale virtuelle. Le programme maître quant à lui affiche une seule fenêtre visualisant par des rectangles la disposition des écrans du mur. Cette fenêtre sert essentiellement à capturer les déplacements et cliques de la souris qui sont reflétés sur le mur par un « curseur mur » pouvant, bien évidement, passer indifféremment d’un écran à l’autre (et donc aussi d’une machine à une autre). Un interface utilisateur (donc fait en GL-ES) est disponible sur un des écrans du mur et est activé au travers du « curseur mur » depuis la machine maître. Avec une souris sans fil connectée à la machine maître, une personne peut manipuler le tout en étant face au mur avec une forte impression d’immersion. Mais ce scénario ne permet pas pour l’instant l’interaction à plusieurs puisqu’il n’y a qu’une seule souris disponible sur la machine maître. En ayant tout ou une partie des écrans du mur en tactile, il serait relativement facile de modifier les programmes pour tenir compte de plusieurs « curseurs mur ». Nous avons essayé le pilotage du « curseur mur » depuis l’iPad mais le rapport en pixels mur/iPad ne va pas dans le sens de la haute précision de pointé et les manipulations deviennent vite très pénibles. Ceci nous a conforté dans l’idée que les tablettes seront idéales comme « fournisseur de données qui sont ailleurs » mais pas forcément comme moyen de contrôle des opérations sur le mur. Pour un moyen de contrôle efficace on est tout de même impressionné par les vidéos du « Electronic Visualization Laboratory » de Chicago montrant des opérations sur un mur fait avec des écrans tactiles (voir « Fleet Commander » sur YouTube) ; c’est « simple et de bon gout » et probablement la solution qui sera la plus facile et la plus simple d’emploi à mettre en place dans des laboratoires.

Comme « fournisseur de données » nous avons déjà les applications ioda, g4view, agora, pmx disponibles sur l’AppStore et GooglePlay, qui peuvent se connecter au programme maître pour envoyer des plots, détecteurs, événements sur le mur. Pour l’instant, un seul fournisseur peut se connecter au maître et il est bien évidement prévu de poursuivre les développements pour que le maître accepte plusieurs fournisseurs de données. L’application ioda peut lire et visualiser des images astronomiques dans des fichiers fits et des histogrammes et ntuples aux formats AIDA-XML et ROOT. g4view peut lire et visualiser un détecteur au format GDML et lancer une simulation avec Geant4. On rappelle que Geant4 est une librairie C++ permettant de faire le suivit de particule dans la matière qui est très utilisée en simulation HEP mais aussi pour le spatial à l’ESA et pour le médical.

Les données HEP

Etant dans un laboratoire de physique, on doit bien évidement se concentrer sur « ce qu’on peut en faire » pour la physique. Déjà le scénario « diaporama » s’est dégagé lors des journées « fêtes de la science ». Vu les réactions des visiteurs (oh, ah !), on voit bien déjà que ce genre de plate-forme peut être un formidable outil pour faire de la communication. Il serait facile d’« enfoncer le clou » et d’envisager de laisser tourner des programmes « 3D immersifs » laissant aux visiteurs une marge d’interaction avec le système ; voir par exemple sur YouTube ce qui a été fait en partenariat avec Google pour la maquette numérique « Paris Métropole 2020 » au Pavillon de l’Arsenal. Ici le mur (en fait une dalle) a un écran tactile maître où le visiteur peut naviguer dans une version très Parisienne de Google map.

Et pour le « vrai travail » de physique ? Nous avons déjà mentionné ioda et g4view qui permettent d’amener des « données génériques » sur le mur. Mais pour vraiment intéresser un physicien il faudrait pouvoir câbler en direct les logiciels de son expérience sur les machines du mur et les tablettes. Comme dit la chanson « parlez moi de moi, y a que ça qui m’intéresse ». Mais la pour l’instant les logiciels des expériences (LHC et autres) sont taillés pour « du Linux pour le batch sur la grille » et le portage sur d’autres OS pour l’interactif n’est pas dans la liste des priorités. Ceci peut se comprendre dans cette phase « traque du Higgs », mais c’est tout de même bien dommage de rester « en aveugle » sur ces questions. Déjà on peut regretter que des event display comme le Panoramix d’LHCb (grosse implication du LAL) ne profiteront probablement jamais de ces nouvelles technologies, mais on peut aussi regretter de couper de facto la voie à l’exploration de scénarios prometteurs comme le contrôle d’une expérience dans un « tout cohérent » avec un mur d’image. (Pour l’instant le physicien en shift a plutôt à faire au scénario « forêt d’écrans » !). Tous ces points ne sont pas du à des barrières technologiques (iOS, Android, OSX sont des UNIX pour lesquels ont a g++) mais plus à des (gros) problèmes de sociologie, de qualité des logiciels, et clairement d’un manque de vision à moyen et long terme de la communauté HEP sur les questions des « logiciels proches de la physique ».

En conclusion, l’année 2010 a ouvert la décennie en fanfare avec de nouvelles technologies interactives comme les tablettes et l’idée des « mur d’image ». Va-t-on pouvoir en profiter pour faire de la physique ? Au LAL, on a déjà sauté dans ce train pour maîtriser la programmation et l’utilisation de ces nouvelles plate-formes, mais cela ne suffira pas si il n’y a pas de volonté côté « logiciels pour la physique » pour « sortir la tête du guidon du batch pour la grille » et être capable d’amener les logiciels des expériences sur ces nouveaux… TGVs ! (Très Grande Visualisation).

Liens utiles :

 Pour le mur du LRI : http://insitu.lri.fr/Projects/WILD

 Portail pour nos logiciels basés sur inlib et exlib : http://softinex.lal.in2p3.fr. Voir la section "wall" pour quelques photos de notre murino. Voir les sections ioda, g4view, pmx, agora pour nos applications iOS et Android. Voir la section "inlib/exlib" pour les idées qui ont mené à ces librairies et pour le gestionnaire de graphe de scène sur GL-ES.

 http://www.evl.uic.edu : le site du EVL de Chicago. Chercher aussi sur YouTube "Fleet Commander".

 http://geant4.cern.ch : le site de la librairie Geant4 de suivi de particules dans la matière.

Pour le pavillon de l’Arsenal chercher par exemple "Maquette numérique, Paris Métropole 2020" sur YouTube.

Guy BARRAND