Compte rendu de la réunion Développement durable du 13 juin 2006

(discussion avec Roman Pöschl : le soft ILC)

Le « soft ILC » est actuellement constitué d’un ensemble de logiciels et d’outils de provenances diverses (Asie, USA, Europe).

Deux sujets principaux sont identifiés comme nécessitant un certain investissement :

• Un système intégré de gestion, installation et distribution du soft
• Un système de bases de données capable de gérer un ensemble important de paramètres tels les constantes de calibration, les paramètres de détecteurs etc., soit, en un mot les conditions data.

Le premier point concerne, entre autres, la question de la gestion de configuration, pour laquelle le service peut proposer des solutions (CMT….). Le problème de la distribution connaît actuellement des solutions s’il s’agit de distribuer des binaires (voir LHcb). Mais s’il s’agit de déployer des sources, avec implémentation automatique, quel que soit le système mis en jeu, il n’y a pas de solution toute faite ; il y a du développement à faire (PACMAN….)

La discussion a beaucoup porté sur le second point. Le thème est actuellement couvert par l’outil LCCD (Linear collider conditions data) qui provient d’un développement effectué pour ATLAS (ConditionDBMySQL) par une équipe de Lisbonne. Dans ATLAS, ce logiciel a été remplacé par COOL. De sorte qu’une évolution vers COOL est envisageable, avec peut-être l’inconvénient de dépendre de l’ensemble de l’environnement CERN. Donc, il semble que LCCD puisse être poussé et développé. Il repose sur LCIO, modèle de persistance de données (la discussion fait apparaître qu’il s’agit bien de ce que Guy Barrand appelle un event model). Ce modèle a vocation à être utilisé tant pour la simulation des détecteurs que pour l’analyse des données (implémentation C++ et Java, avec une API commune). Un point extrêmement positif est que LCIO semble avoir été adopté comme standard sur les trois continents. Du côté simulation des détecteurs, un outil majeur est Mokka (qui utilise GEANT4 ; beaucoup développé au laboratoire de l’Ecole polytechnique (Gabriel Musat)). Il faut signaler que, pour le moment, il existe plusieurs modèles de description de détecteurs, en fonction de l’origine géographique des équipes – Mokka (Europe), SLIC, LCDG4 (US), Jupiter (Asie) – et qu’aucun accord n’a semble-t-il, été recherché pour un standard (ILC n’est pas encore une collaboration, au sens usuel du terme en physique des particules ; et la question d’un framework commun abouti fatalement à des discussions « politiques »). Pour ce qui est de l’analyse et de la reconstruction un outil est Marlin (Modular analysis and reconstruction of the linear collider). La visualisation est repérée comme un point faible. Les histogrammes sont faits dans Marlin (AIDA, mais aussi ROOT) ; un objectif serait de généraliser l’usage de LCIO pour cet outil.

Enfin, il faut noter que la Grille est actuellement utilisée. Les soft sont installés sur tous les sites (Tier…) ; un problème peut se poser avec les bases de données centralisées. Il faut une réplication locale (synchronisation ?)

Conclusions

Trois thèmes éventuels de collaboration du groupe développement au projet ILC ont été identifiés. D’abord la visualisation et l’interface graphique. Guy Barrand propose d’installer Marlin et de faire quelques recherches sur la conception d’une interface commune, sur la base des conditions existantes. En second lieu des réflexions prospectives peuvent être menées sur la gestion des conditions data (Antoine Pérus ?). Enfin, de manière un peu plus lointaine (au regard de la R&D nécessaire) on peut envisager une prospective sur le déploiement automatisé (Serge Du, Antoine Pérus).

Remarque : une collaboration est déjà engagée et formalisée sur la simulation de l’effet faisceau-faisceau au point de collision de la machine (programme guineapig).