compte-rendu de la réunion développement durable du 29 novembre 2005
La réunion a été consacrée à un tour de table concernant les nouvelles et activités en cours.
Guy Barrand a assisté, à Grenoble, à une "session utilisateurs" de GEANT4. On remarque, en ce domaine une poussée des utilisateurs dans le domaine biomédical : un patient est modélisé dans GEANT4 comme s'il était un détecteur! Un logiciel particulier de simulation PET (émission tomographique), GATE, est développé sur la base de GEANT4. Du côté de la Grille, une interface est développée : DIANE.
Dans l'expérience AUGER (J.N. Albert) une activité est déployée avec des physiciens pour effectuer une revue des bases de données utilisées par les différents logiciels. Il s'agit de rendre compatibles les systèmes basés d'une part sur java, d'autre part sur C++. Les difficultés surgissent du fait que les applications fondées sur Mysql ne sont pas portables et que C++ n'offre pas un standard gratuit reconnu par les producteurs de bases de données (ODBC est payant et mal adapté à notre discipline). Java propose un standard gratuit d'accès aux bases de données.
Il existe, au sein de la communauté astrophysique, une acitvité de recherche et développement sur une interface de type 'langage expert' pour réaliser une encapsulation de Java dans C++. On devrait pouvoir faire le point dans trois mois environ.
Dans Planck (S. Du) les bases de données ne sont pas objet (SQL). La PIOLIB est en phase de réimplémentation. Une activité est déployée (F. Touze) pour paralléliser le map-making L2 au centre de calcul de Lyon (MPI). Cela se fait dans le système PISTOO récemment disponible à Lyon, avec les aleas relatif à tout nouveau système.
Concernant ATLAS (J. Hrivnac) une interface JAS (Java analysis studio) permet d'accéder (à travers une couche Python) au framework C++ ATLAS, ATHENA.
Dans le projet SGSDA, des essais ont été réalisés pour traité des masses importantes de données (100 millions d'étoiles EROS) dans une base ORACLE. Des optimisations (segmentations de données...) ont permis d'améliorer les performances. Une première conclusion est que ORACLE résiste à l'augmentation des masses à traiter, alors qu'on sait que Mysql a tendance à ployer sous la charge. Le problème est que ORACLE coûte assez cher et qu'il nécessite des experts pour en assurer la gestion. Il faut des solutions multibases.
