imprimer
n°17
Juillet
2011
Le CCRI nouveau est arrivé
Le CCRI est heureux de vous annoncer sa renaissance en ce mois de Juin 2011. La composition du CCRI (membres nommés) est au 1er juin 2011 la suivante : Animateur ASR : Muriel Gougerot (LAPP) Animateur DEV : Christian Helft (LAL) Contact Laboratoires : Dirk Hoffmann (CPPM) Contact Laboratoires : Fabian Lambert (LPSC) Contact Laboratoires : Françoise Virieux (APC) Contact Centre de Calcul : Pierre-Etienne Macchi (CC-IN2P3) Communication : Eric Legay (CSNSM) Représentant IRFU : Pierrick Micout Contact avec les autres réseaux : Christian Helft, Frédérique Chollet

Je rappelle que le rôle essentiel du CCRI est de coordonner les actions de notre réseau des informaticiens de l’IN2P3 et de l’IRFU (le RI3), en particulier :

en mandatant des responsables d’actions transverses comme l’organisation des Journées Informatiques, pour 2012, Françoise Virieux s’y colle :-) ; en favorisant des réflexions d’envergure nationale sur la formation, la veille technologique, la valorisation et le métier d’informaticien à l’IN2P3 ; en encourageant la création de groupes de travail sur des sujets d’intérêt commun (options technologiques, mutualisation des ressources, achats groupés, etc.) ; en définissant et maintenant les moyens nécessaires à l’existence d’un site Web et d’autres moyens de circulation de (...)

lire la suite

Echanges

Partager le savoir / Sharing Knowledge

« Partager le savoir/Sharing Knowledge » est une fondation qui est née au début des années 2000 ayant les objectifs suivants : encourager le dialogue entre scientifiques provenant du Nord, du Sud et de l’Est de la Méditerranée ; contribuer à la réalisation d’un réseau issu de la société civile aboutissant à des projets concrets visant le développement durable ; contribuer à la réduction des inégalités et des déséquilibres entre nations ; organiser des conférences pluridisciplinaires, sur le modèle des Conférences ”Partage du Savoir en Méditerranée”, initiées sous l’égide de l’AFAS depuis 2004 par Robert Klapisch et traitant de façon récurrente de sujets tels que :

lire la suite

Grand instrument

LSST - La suite

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. Lors de la derniere lettre, un premier article a présenté le projet LSST. Dans cet article, nous détaillerons les points forts du cahier des charges du CCS, décrirons l’architecture générale, et expliquerons les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java.

Le projet de logiciel de contrôle commande de la caméra, le CCS, est subdivisé en une quinzaine de sous-systèmes tels que :

  • l’échangeur de filtres ;
  • l’obturateur ;
  • la gestion du froid ;
  • la gestion du vide ;
  • la gestion de la température ;
  • la gestion de la puissance électrique ;
  • l’acquisition de données.

lire la suite

Controle/commande

Institut Laue-Langevin

L’Institut Laue-Langevin (ILL) est un centre international de recherche à la pointe de la science et de la technologie neutroniques et est situé dans la ville de Grenoble dans le sud-est de la France. L’ILL a été fondé en 1967 sous la forme d’une entreprise binationale franco-allemande rejointe en 1973 par le Royaume-Uni. A présent, au côté de ces trois associés, 12 autres pays sont membres scientifiques de l’institut : l’Espagne, la Suisse, l’Autriche, l’Italie, la République Tchèque et plus récemment la Suède, la Hongrie, la Belgique la Slovaquie, le Danemark, la Pologne et l’Inde. L’institut exploite la source de neutrons la plus puissante dans le monde, fournissant des neutrons à 40 instruments de haute performance constamment modernisés.

lire la suite

Calcul

Rencontres LCG-France 2011 (session de printemps)

LCG-France organise depuis maintenant plus de six ans deux rencontres par an au cours desquelles sont discutés l’état d’avancement du projet, l’évolution de l’infrastructure des sites et les activités de calcul des expériences LHC.

Les 30 et 31 mai derniers, la session de printemps 2011 s’est tenue pour la première fois à l’IPHC (Institut Pluridisciplinaire Hubert Currien) à Strasbourg et a réuni une cinquantaine de personnes (voir le programme).

lire la suite

Equipe

Responsables éditoriaux : Dominique Boutigny et Cristinel Diaconu
Comité de rédaction : Dominique Cathala, Virginie Dutruel, Sébastien Grégoire, Eric Legay, et Gaëlle Shifrin

Agenda
EGI Technical Forum 2011
Le plus grand événement européen sur les grilles informatiques, l’EGI Technical Forum, se déroule (...)

en savoir plus

Premières rencontres scientifiques GIS France Grille
Le GIS France Grilles organise ses premières rencontres scientifiques. Elles se tiendront à (...)

en savoir plus

JDEV2011 : Journées nationales sur le développement logiciel dans la Recherche et l’Enseignement Supérieur
Les objectifs de ces journées nationales sont les suivants : Etablir un premier contact entre (...)

en savoir plus

ACAT 2011
Le 14ème Workshop international ACAT (Advanced Computing and Analysis Techniques in Physics (...)

en savoir plus

Workshop NARVAL
Narval est un environnement de travail, dont le coeur est écrit en Ada 2005, et qui permet (...)

en savoir plus

Rechercher
Abonnement
Pour vous abonner/désabonner, suivez ce lien.
Proposer un article
Vous souhaitez proposer un article ? Envoyez un mail à LettreInformatique@in2p3.fr.
logo CCIN2P3
© 2011 CCIN2P3
n°17
Juillet
2011
Le CCRI nouveau est arrivé

Réseau

Le CCRI est heureux de vous annoncer sa renaissance en ce mois de Juin 2011. La composition du CCRI (membres nommés) est au 1er juin 2011 la suivante :

  • Animateur ASR : Muriel Gougerot (LAPP)
  • Animateur DEV : Christian Helft (LAL)
  • Contact Laboratoires : Dirk Hoffmann (CPPM)
  • Contact Laboratoires : Fabian Lambert (LPSC)
  • Contact Laboratoires : Françoise Virieux (APC)
  • Contact Centre de Calcul : Pierre-Etienne Macchi (CC-IN2P3)
  • Communication : Eric Legay (CSNSM)
  • Représentant IRFU : Pierrick Micout
  • Contact avec les autres réseaux : Christian Helft, Frédérique Chollet

Je rappelle que le rôle essentiel du CCRI est de coordonner les actions de notre réseau des informaticiens de l’IN2P3 et de l’IRFU (le RI3), en particulier :

  • en mandatant des responsables d’actions transverses comme l’organisation des Journées Informatiques, pour 2012, Françoise Virieux s’y colle :-) ;
  • en favorisant des réflexions d’envergure nationale sur la formation, la veille technologique, la valorisation et le métier d’informaticien à l’IN2P3 ;
  • en encourageant la création de groupes de travail sur des sujets d’intérêt commun (options technologiques, mutualisation des ressources, achats groupés, etc.) ;
  • en définissant et maintenant les moyens nécessaires à l’existence d’un site Web et d’autres moyens de circulation de l’information au sein du réseau (listes de courrier, forum, lettre électronique etc.) ;
  • en assurant une représentation du réseau dans les comités informatiques nationaux et internationaux ;
  • en informant la communauté des usagers et expériences des actions du réseau.
  • en missionnant un ou plusieurs responsables d’école informatique IN2P3 annuelle
  • en établissant un état global des ressources informatiques des deux instituts, aussi bien sur le plan matériel qu’humain, grâce à des enquêtes et remontées d’information via les chefs de service et correspondants laboratoire, ou tout autre moyen approprié.

Cette partie présentative passée, je voudrais vous donner ma vision personnelle de ce qu’est le CCRI, de ce que nous pouvons en attendre et surtout comment chaque membre du RI3 peut agir en son sein.

Réseaux spécialisés

Chacun des deux sous-réseaux (ASR et DEV) est animé par un membre du CCRI. Le rôle de ces animateurs est de prolonger le dialogue entre informaticiens de nos instituts au delà des structures existantes (transverses au laboratoire et aux projets), de susciter ou accompagner la définition des actions de formation et de veille technologique, de faire émerger des actions collectives permettant de mettre en commun les compétences.

L’ensemble du réseau peut contribuer à ces animations au travers des comités de pilotages en cours de formation. N’hésitez pas à contacter Muriel ou Christian, si vous avez envie de vous impliquer dans la vie de votre réseau. C’est grâce à l’action de membres du réseau que les écoles IN2P3, les webinaires, la lettre informatique, les groupes de travail, etc sont possibles.

Contact ou correspondant CCRI ?

Un peu de définition tout d’abord :

Chaque service informatique doit / devrait avoir choisi de façon collégiale un correspondant CCRI. Cette personne est le point de contact privilégié par le CCRI pour initier les discussions, recevoir et transmettre des informations. Ce correspondant devrait être une personne représentant le mieux son service, pas le chef ou un membre du CCRI.

Chacun des contacts laboratoires se doit de connaître le fonctionnement de l’informatique au sein de « ses » laboratoires. Il se doit d’être en liaison avec le correspondant CCRI et le chef de service pour comprendre les projets et les attentes en matière d’informatique du laboratoire. En retour, ils rapportent régulièrement auprès de « leurs » laboratoires les activités du CCRI.

Tout membre du réseau peut se mettre en rapport directement avec un contact CCRI pour faire remonter une information ou pour répondre à une interrogation.

Communication

Un de mes objectifs prioritaires d’un point de vue communication est de faire évoluer notre site web. Ce site a le mérite d’exister mais n’est pas, enfin de mon point de vue, satisfaisant.

Dans les prochains mois, avec toutes les bonnes volontés qui se dénonceront à moi, je tirerais un bilan des fonctionnalités existantes du site actuel. En parallèle à cet état des lieux, j’aimerais un retour de l’ensemble des membres sur ce qu’ils attendent, ou pas, de ce site web. Une fois ces deux étapes effectuées, en fonction des disponibilités des personnes qui se seront manifestées, on fera le boulot !

Qui est volontaire ?

Comme on peut le constater, il restera toujours de nombreuses opportunités pour participer à l’animation du réseau. Nous vous invitons à y répondre. En particulier, le rôle de correspondant laboratoire peut faire l’objet d’une rotation plus fréquente que les autres fonctions, et il constitue une bonne façon de commencer à contribuer à l’animation du réseau.

Prochains rendez-vous :

  • webinaire (ou téléséminaire) 20 septembre 2011, 14h00
  • réunion plénière avec les chefs de service après la rentrée
  • journées informatiques prévues fin 2012

Eric LEGAY, pour le CCRI

n°17
Juillet
2011
Steven Newhouse : "Le Cloud n’est pas une préoccupation, mais plutôt une opportunité ! "

Directeur EGI (European Grid Infrastructure)

Le prochain Technical Forum est prévu en septembre prochain à Lyon. Steven Newhouse, directeur d’EGI, a accepté de répondre à nos questions....

-  Quelles sont les perspectives et les nouvelles tendances émergentes au sein de l’infrastructure de grille européenne ?

Suite à cette première année d’activité pour EGI, deux objectifs interdépendants émergent pour l’avenir :

  1. étendre la communauté des utilisateurs,
  2. mettre à leur disposition une infrastructure plus flexible et évolutive.

Ces deux objectifs sont liés, du fait que la plupart de nos utilisateurs ont besoin d’utiliser des logiciels développés au sein de leur propre communauté, mais qui ne sont pas encore déployés à l’échelle européenne.

EGI peut apporter son aide au travers du déploiement et de l’exploitation des logiciels, par le biais de son réseau de fournisseur de ressources (à la fois NGIs et EIROs), mais nous devons être en mesure d’apporter ce soutien à l’ensemble des communautés, sans solliciter davantage de travail au niveau de l’infrastructure actuelle.

Sur ce point, une infrastructure dynamique et plus flexible, au travers de technologies telles que la virtualisation, permettrait de rallier les communautés d’utilisateurs du cloud

-  Est-ce que le Cloud est une préoccupation majeure pour l’avenir ?

Ce n’est pas une préoccupation mais une opportunité.

Il existe maintenant des ressources commerciales que nous serions capables d’utiliser, en tant que communauté, pour alléger de manière rentable notre charge globale.

Nous pourrions également fournir une valeur ajoutée sur certains services, qui répondraient aux besoins de notre communauté scientifique mais qui ne peuvent pas être couverts par ces offres commerciales. Nous pouvons citer par exemple le cas des transferts de données massifs ou de l’analyse intensive sur données distribuées.

Nous devons travailler sur l’évolution de notre modèle opérationnel afin d’offrir le meilleur environnement possible à nos utilisateurs.

- Pouvez-vous nous expliquer ce qu’est le Technical Forum : comment est-il né ? Quels sont ses objectifs ?

Le Technical Forum s’inscrit comme une continuation des conférences périodiques durant les projets European Data Grid tout d’abord, puis EGEE. Le Technical Forum évolue comme un espace de support à de nombreuses activités liées à EGI. Des projets de support comme eScienceTalk et SIENA, des activités techniques telles que StratusLab, EMI et IGE, ainsi que de nombreux autres projets nationaux ou européens, sont inclus à son programme.

Rassembler cette communauté tous les six mois, afin d’enrichir les contacts et les partenariats, de partager les innovations de différents projets, et de puiser l’inspiration nécessaire pour fournir une infrastructure pour les scientifiques à travers l’Europe, est une véritable valeur ajoutée.

-  Pourquoi la ville de Lyon a-t-elle été choisie pour ce Technical Forum ?

La ville de Lyon a été choisie suite à l’appel mené et arbitré par le conseil EGI. La proposition du Centre de Calcul de l’IN2P3 et de France-Grilles a été jugée très attractive. Lyon offre non seulement une excellente infrastructure pour la conférence elle-même, mais également une facilité d’organisation grâce à l’expertise de l’équipe sur place.

De plus, Lyon se trouve être un lieu idéal (grâce à ses bars et ses restaurants) pour favoriser la convivialité et renforcer les liens collaboratifs qui sont vitaux pour la communauté EGI.

PROPOS RECUEILLIS ET TRADUITS (avec l'aide de Gilles Mathieu) PAR D.C

n°17
Juillet
2011
Partager le savoir / Sharing Knowledge

« Partager le savoir/Sharing Knowledge » est une fondation qui est née au début des années 2000 ayant les objectifs suivants : encourager le dialogue entre scientifiques provenant du Nord, du Sud et de l’Est de la Méditerranée ; contribuer à la réalisation d’un réseau issu de la société civile aboutissant à des projets concrets visant le développement durable ; contribuer à la réduction des inégalités et des déséquilibres entre nations ; organiser des conférences pluridisciplinaires, sur le modèle des Conférences ”Partage du Savoir en Méditerranée”, initiées sous l’égide de l’AFAS depuis 2004 par Robert Klapisch et traitant de façon récurrente de sujets tels que :

  • les besoins de base (eau, énergie, nourriture),
  • l’accès à la civilisation numérique,
  • l’accès à la science fondamentale,
  • la prévention des catastrophes naturelles et des catastrophes liées à l’activité humaine,
  • différents thèmes dictés par l’actualité.

Cette année, la 6ème édition de ces rencontres s’est tenue à Malte, sous l’intitulé : « Pour accompagner un monde en mouvement ».

Parmi les sujets traités concernant l’informatique, a été évoqué l’internet pour l’Afrique qui revêt un double aspect : accès à la Grille de Calcul qui permet à un chercheur basé à Marrakech ou à Johannesburg d’avoir accès “en direct” aux expériences du CERN et l’accès aux nouveaux câbles sous-marins de fibre optique qui rendront le haut-débit enfin abordable pour le public. D’autre part, comme l’ont constaté les participants, l’internet mobile est sans nul doute promis à un grand avenir en Afrique. Il a même joué un rôle majeur dans la diffusion des révolutions dans les pays arabes.

La coopération régionale transfrontalière constitue pour les scientifiques africains, le meilleur moyen de mutualiser les ressources et d’atteindre la masse critique leur permettant de devenir des partenaires significatifs dans la coopération internationale. L’Internet, dans cette situation, est indispensable au vu des énormes distances du continent. L’édition 2007 de « Partage des Savoirs » qui s’est déroulée à Montpellier avait recommandé de donner la priorité à la liaison régionale entre NRENs et avec l’Europe, malgré les énormes obstacles tels que la faible connectivité, les coûts élevés, etc. Ces recommandations ont été favorablement accueillies lors d’une rencontre à Bruxelles en janvier 2008, mais il restait à les faire approuver par les 55 états africains.

C’est en octobre 2008 que le Collège des Commissaires Européens et Africains a mis deux de ces recommandations (Africa Connect et AXIS) sur une liste de priorités parmi une longue liste de 19 “propositions phares”. FEAST, une étude de faisabilité terminée en 2010, a montré en particulier la nécessité pour tous ces pays de mettre en place des NRENs. Durant la conférence de Malte, ont pu participer les leaders des trois groupes NRENs du continent Africain : Ubuntunet pour le Sud et l’Est africain, WACREN pour l’Afrique de l’Ouest et du Centre et ASREN pour les Etats Arabes. Le 11 mai 2011 à Gaborone, il a été annoncé que l’Europe contribuera à hauteur de 14,75 millions d’euros à l’amélioration des infrastructures des universités africaines.

La Grille de Calcul est maintenant un succès et son utilisation pour les pays en développement doit être promue. C’est pour cette raison que les problèmes entravant la participation africaine à l’European Grid Initiative (EGI) doivent être résolus. L’émergence de réseaux académiques et de recherche multinationaux est à saluer. Néanmoins, il faut noter la persistance de problèmes en matière de connectivité régionale et nationale. Les moyens de dépasser ces derniers impliquent de casser les monopoles nationaux de télécommunication, de négocier des tarifs préférentiels et d’utiliser la capacité de la fibre noire existant le long des lignes électriques, des pipelines, chemins de fer et routes. La priorité devrait être donnée au pilotage et à l’encouragement des applications scientifiques locales, par exemple, au travers de l’Exchange Program to Advance e-Infrastructure Knowhow (EPIKH).

Références et liens Internet :

Fairouz MALEK

n°17
Juillet
2011
LSST - La suite

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. Lors de la derniere lettre, un premier article a présenté le projet LSST. Dans cet article, nous détaillerons les points forts du cahier des charges du CCS, décrirons l’architecture générale, et expliquerons les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java.

Le projet de logiciel de contrôle commande de la caméra, le CCS, est subdivisé en une quinzaine de sous-systèmes tels que :

  • l’échangeur de filtres ;
  • l’obturateur ;
  • la gestion du froid ;
  • la gestion du vide ;
  • la gestion de la température ;
  • la gestion de la puissance électrique ;
  • l’acquisition de données.

Le CCS a pour objectif de contrôler et coordonner les actions des différents sous-systèmes de la caméra. Le CCS est l’interface entre le logiciel de contrôle du télescope, le TCS, et les sous-systèmes de la caméra. Il doit fournir aux utilisateurs de la caméra et du télescope tous les outils informatiques permettant de contrôler, commander et configurer la caméra. Cela implique des consoles, des bases de données télémétriques et de la configuration.

Le CCS doit gérer différents modes opératoires :

  • mode normal ou automatique lorsque la prise de données se fait de manière automatique pendant le balayage du ciel lorsqu’il n’y a pas d’incidents ;
  • mode engineering (maintenance) lors de la construction de la caméra ou lors des opérations de maintenance de la caméra ;
  • mode emergency, lorsqu’un incident majeur intervient (panne de courant électrique ou tremblement de terre imminent). Il s’agit alors de mettre le matériel dans un état où le risque de dommages est le plus faible.

Ce que ne fait pas le CCS

Le CCS ne fait pas d’acquisition de données mais il est l’interface entre le logiciel d’acquisition de données et le logiciel de contrôle du télescope. Ainsi le CCS ne gère pas le grand flux de données générées par les prises d’images.

Les contraintes

Du fait que nous ne faisons pas d’acquisition de données, nous n’avons pas de contraintes « temps réel », mais plutôt de « slow control ». La contrainte la plus importante est la durée de vie du logiciel. En effet, depuis les premières études en 2006 et la fin d’exploitation du télescope autour de 2030, il se sera écoulé bien plus de quinze ans. Il est vraisemblable que les personnes qui auront à maintenir ce logiciel ne seront pas les mêmes que ceux qui le développent. Cette longue durée de vie requise impose d’une part une grande qualité dans l’écriture du code et de la documentation, d’autre part de concevoir le logiciel de manière à le rendre indépendant des briques de logiciel libre que nous utilisons pour le construire.

La fréquence d’estampillage des événements internes de la caméra doit être réalisée avec une précision relative (temps entre deux événements) d’une milliseconde et une précision absolue (temps par rapport au temps externe) de dix millisecondes. L’observatoire fournit le référentiel de temps et le CCS est chargé de distribuer ce temps à tous les sous-systèmes. Le CCS doit être capable de fonctionner lors de la construction ou les opérations de maintenance sur les bancs de test de la mécanique ou de l’électronique lorsque nous ne disposons que d’un environnement minimal. Il doit pouvoir tourner sur une machine fonctionnant sous unix, de type PC104.

Description générale du fonctionnement du CCS

Le cœur du CCS repose sur trois bus de communication (Command, Status et Log). Ces trois bus relient entre eux les sous-systèmes au-dessus d’un réseau TCP/IP sur Ethernet.

Command bus

Le bus de commandes permet d’acheminer les commandes à chaque sous-système, et les accusés de réception de ces commandes.

Status bus

Chaque sous-système publie à intervalle régulier les données décrivant son état (position, température, pression, type du filtre en ligne) sur le bus de status. Au démarrage, il publie aussi ses données de configuration. Les données qui circulent sur le bus de status sont ensuite consolidées dans une base de données locale puis transmises à l’observatoire.

Log bus

Le bus de log recueille toutes les données jugées utiles pour chaque sous-système à des fins de détection d’erreur et de diagnostic. Ces données sont conservées dans une base de données locale et permettent une analyse plus fine du comportement de la caméra, principalement pendant les phases de maintenance et de construction.

En mode opératoire normal, automatique, des ordres de haut niveau, s’adressant à la caméra vue dans son ensemble, viennent du logiciel de contrôle du télescope, OCS (Observatory Control System). Ces ordres de haut niveau sont transformés par le cœur du CCS en une séquence de commandes dont chacune s’adresse plus particulièrement à un sous-système de la caméra. Par exemple, l’ordre : « Take a single science exposure of 15 seconds with filter g » se traduit par une série de commandes adressées :

  • au FCS : « move filter g online »,
  • au DAQ (Data Acquisition system) : « clear CCD »
  • à l’obturateur : « open shutter 15s »,
  • puis, « close shutter »
  • au système d’acquisition de données : « read out CCD »
  • etc...

En mode de maintenance, des commandes peuvent être adressées à chaque sous-système par l’intermédiaire d’une console. Ces consoles peuvent être locales ou distantes. Pour garantir la sécurité des personnes et du matériel, un système de verrou est implémenté afin que ces commandes ne puissent venir que d’une seule console à la fois. Le CCS est conçu comme un canevas permettant aux développeurs Java des sous-systèmes de se concentrer sur leur développement spécifique. Ainsi les principales fonctions prises en charge par le cœur du CCS sont les suivantes :

  • communication sur les trois bus,
  • sauvegarde automatique dans les bases de données,
  • description de la configuration du sous-système en XML.

Cependant, un développeur de sous-système peut utiliser le langage de son choix. L’équipe de développement du cœur lui offrira du support pour écrire une interface communiquant avec les trois bus du CCS. Cette pratique n’est pas recommandée car elle rend les opérations de maintenance du code plus complexes.

Nos choix technologiques et les raisons de ces choix

Dès la conception du logiciel, nous avons choisi d’utiliser des briques de logiciel libre chaque fois que c’était possible. Pour rendre notre logiciel indépendant de ces briques, nous avons écrit une interface au sens Java du terme afin de n’avoir à réécrire que cette interface en cas de changement.

Ainsi :

  • la communication autour des trois bus est réalisée par Java Message Service ;
  • la population des bases de données est réalisée avec Hibernate ;
  • la description de la configuration des sous-systèmes est réalisée avec Spring ;
  • la réalisation de contraintes entre des éléments des sous-systèmes (par exemple le verrou A ne peut être ouvert que si le verrou B est fermé) peut-être réalisée avec AspectJ, un outil Aspect Oriented Programming.

Pourquoi développer un logiciel spécifique et ne pas utiliser des outils commerciaux disponibles sur étagère (COTS ou SCADA) ?

Nous avons envisagé PVSS et EPICS et étudié les expériences heureuses ou malheureuses de ces logiciels pour différents télescopes. Or dans l’équipe du SLAC avec laquelle travaillons sur ce projet, les expériences malheureuses avec EPICS sont plus fréquentes que les heureuses.

Nos conclusions sont les suivantes :

  • la courbe de prise en main de ces logiciels est souvent exponentielle : pour faire des choses basiques tout va bien, mais dès que c’est plus complexe, la difficulté augmente très vite ;
  • ces logiciels ont souvent une documentation insuffisante ;
  • cela peut être très ardu de coder des fonctionnalités qui n’ont pas été prévues par le concepteur du logiciel ;
  • adapter ces logiciels à nos besoins requiert souvent l’écriture de beaucoup de code de haut et de bas niveau ;
  • il y a une incertitude sur la durée de vie de ces logiciels, or c’est une contrante forte de notre projet de produire un logiciel avec une très longue durée de vie.

Pourquoi JAVA ?

  • de plus en plus de logiciels sont codés en Java dans tous les domaines, de l’industrie aux télécommunications en passant par la finance, sa longévité ne fait pas de doute ;
  • Java est facile à débugguer ;
  • les performances des codes écrits en JAVA n’ont plus rien à envier à ceux écrits en C++ ou même en C ;
  • le nombre et la richesse des librairies disponibles en Java sont énormes, en particulier pour la communication, ce qui fait que réécrire les fonctionnalités d’EPICS n’est pas un gros travail ;
  • communiquer avec les pilotes du matériel est facilité par JNI et cela a été démontré par la réalisation du tout premier prototype ;
  • nous avions une bonne compétence de JAVA dans l’équipe ;
  • nous avions la possibilité de réutiliser le code écrit par le SLAC pour le projet Fermi, autour de JAS pour la réalisation des consoles et écrans de contrôle et l’analyse des données télémétriques (affichage de courbes)

Description détaillée du logiciel

Le cœur du système : un canevas pour construire les sous-systèmes

Le cœur du CCS fournit des classes Java permettant de construire rapidement un sous-système sous la forme d’un système modulaire assemblant des modules réutilisables. L’assemblage des modules est réalisé par Spring Framework et décrite par XML. Chaque module communique avec les trois bus pour recevoir des commandes ou publier son status. Les modules s’observent les uns les autres (pattern Observer). Parmi ces modules l’un deux, le « main Module », joue le rôle de façade (pattern Façade) pour le sous-système. En mode normal, seul ce module principal reçoit des commandes venant du CCS. En mode maintenance tous les modules peuvent recevoir des commandes individuellement depuis une console.

Un des modules joue le rôle d’interface avec le matériel, soit directement avec les librairies d’entrée-sortie de Java (Java IO), soit par JNI si le pilote est écrit en C ou un autre langage.

Exemple d’un sous-système : le contrôle commande de l’échangeur de filtre.

Le FCS est construit avec le framework. Il est composé de quatre principaux modules : le « main » et trois modules gérant les différents composants mécaniques de l’échangeur de filtres :

  • le « carrousel »,
  • l’ « autochanger »
  • le « loader »

Chacun de ces modules peut fonctionner indépendamment des autres sur leur banc de test respectif ou lorsqu’on passe en mode maintenance. La communication avec les moteurs et les capteurs est régie selon le protocole CANopen au-dessus d’un bus CAN via un contrôleur. Le choix de CANopen a été fait par l’équipe de mécaniciens, et nous l’avons validé. En effet, le choix d’un protocole largement répandu dans le milieu industriel ouvre un large éventail de fournisseurs. Dans le FCS le protocole CANopen est modélisé par une interface Java, ainsi il suffit de changer la classe implémentant le contrôleur en cas de changement.

Où nous en sommes (notre plan de développement)

Actuellement dans une phase de conception, nous avons développé plusieurs prototypes dont un prototype de FCS avec un simulateur du matériel. Le logiciel de contrôleur de l’obturateur, pour lequel un prototype mécanique existe depuis longtemps, fonctionne déjà dans une version simplifiée, adaptée au prototype. Ainsi l’ensemble de la chaîne de commandement depuis les ordres de haut niveau jusqu’aux ordres de bas niveau pour commander le moteur est validé.

Parallèlement aux développements du cœur du logiciel, nous adaptons le prototype du FCS pour un banc de test de la mécanique qui sera installé au CPPM début 2012. Au cours de l’année 2012, nous disposerons d’un banc de test à l’échelle un du système d’échangeur de filtres. Ces tests permettront de valider la mécanique et le contrôle.

Conclusion

Le télescope LSST devrait voir sa première lumière en 2019 et sa caméra doit être assemblée durant l’année 2017 et testé au Slac en Californie, puis au Chili au cours de l’année 2018. D’ici là, des choix différents peuvent être faits par les différentes équipes techniques construisant la caméra. Notre pari est qu’avec notre logiciel maison écrit en Java, réutilisant beaucoup de pièces de logiciel libre sans jamais y être liés, nous réussirons à nous adapter rapidement aux changements. C’est autant de temps gagné pour la documentation et le « refactoring » permanent du code pour produire un code de qualité. Verdict en 2019 !

Éric AUBOURG, Françoise VIRIEUX

n°17
Juillet
2011
Institut Laue-Langevin

L’Institut Laue-Langevin (ILL) est un centre international de recherche à la pointe de la science et de la technologie neutroniques et est situé dans la ville de Grenoble dans le sud-est de la France. L’ILL a été fondé en 1967 sous la forme d’une entreprise binationale franco-allemande rejointe en 1973 par le Royaume-Uni. A présent, au côté de ces trois associés, 12 autres pays sont membres scientifiques de l’institut : l’Espagne, la Suisse, l’Autriche, l’Italie, la République Tchèque et plus récemment la Suède, la Hongrie, la Belgique la Slovaquie, le Danemark, la Pologne et l’Inde. L’institut exploite la source de neutrons la plus puissante dans le monde, fournissant des neutrons à 40 instruments de haute performance constamment modernisés.

En tant qu’institut de services, l’ILL met ses installations et son expertise à la disposition des visiteurs scientifiques. Chaque année, environ 2 000 chercheurs de plus de 30 pays viennent travailler à l’ILL. Plus de 800 expériences, sélectionnées par un comité scientifique, sont pratiquées annuellement. La recherche se concentre principalement sur la science fondamentale dans une grande variété de domaines, comme la physique de la matière condensée, la chimie, la biologie, la science des matériaux, l’ingénierie, la physique nucléaire et la physique des particules. Les expériences de diffusion neutronique ont apporté une contribution significative à notre compréhension de la structure et du comportement de la matière biologique condensée. Ceci a permis de concevoir de nouveaux produits chimiques comme des médicaments et des polymères mais également des matériaux utilisés dans l’électronique et l’ingénierie structurelle. Toutes ces études neutroniques offrent un aperçu unique sur la nature des systèmes complexes au niveau le plus fondamental.

Service Contrôle des Instruments

Dans ce cadre, le Service de Contrôle des Instruments (SCI) fournit le support électronique et informatique à l’ensemble des 40 instruments officiels de l’institut. Ce support s’étend également à l’ensemble des instruments et équipements qui sont utilisés par La Division des Projets Techniques (DPT), afin de tester ses éléments optiques et mécaniques ainsi que ses détecteurs. La première priorité du Service de Contrôle des Instruments (SCI) est de fournir un support aux instruments permettant une exportation optimale du faisceau de neutron. En pratique, cela consiste à des interventions régulières afin de remplacer le matériel électronique ou informatique pour prévenir les pannes dues au vieillissement, de gérer une réserve de matériel pour les pannes intempestives, et également d’anticiper les évolutions techniques aussi bien électroniques qu’informatiques.

Du point de vue électronique, chaque instrument est équipé d’un ou plusieurs châssis industriels VME, support de l’électronique d’acquisition, de contrôle de mouvement et d’une majorité des cartes I/O. Un nombre conséquent de châssis Nuclear Instrumentation Module (NIM) assure l’alimentation de haute qualité, nécessaire pour l’ensemble de nos amplificateurs moteur et pour l’électronique analogique. Néanmoins, pour quelques petits instruments, une solution PC combiné à des contrôleurs commerciaux, a été préféré au VME afin de limiter le coût de l’installation. Ce haut degré de standardisation a permis un gain effectif en terme de coût et de nombre d’équipements nécessaires pour la maintenance, et favorise des interventions rapides en cas de panne. De plus, un développement commun permet à l’ensemble des instruments de bénéficier rapidement des évolutions et améliorations techniques.

NOMAD : Un outil de contrôle moderne

Du point de vue informatique, la majorité de nos instruments bénéficie maintenant de NOMAD, un nouveau séquenceur en développement au SCI depuis 2006. Ce projet a été rendu nécessaire car le précédent système présentait des limitations majeures : il était basé sur des technologies vieillissantes, souffrait d’absence d’architecture, et n’offrait pas assez de possibilités pour intégrer les nouvelles fonctionnalités indispensables à la nouvelle génération des instruments de l’ILL. La ligne de conduite pour son développement a été l’optimisation des ressources humaines au travers d’un code intégralement partagé entre l’ensemble des instruments, et d’une architecture orientée vers les utilisateurs au travers d’une interface uniforme et ergonomique. Le partage de l’ensemble du code sur nos instruments présente deux avantages majeurs. Premièrement, les méthodes d’optimisation et les routines scientifiques, de même que la correction des bugs sont immédiatement disponibles sur tous nos instruments, et deuxièmement, cela permet de réduire les temps de développement et de maintenance. De plus, une large gamme d’outils de tests et de mise au point a été développée afin de permettre aux ingénieurs et techniciens en électronique une plus grande efficacité lors des installations ou des changements de configuration de nos instruments.

NOMAD est basé sur une architecture client/serveur, il se déploie sur un système LINUX. Le serveur, écrit en C++, en est le corps métier, il contient l’ensemble de nos drivers et de nos méthodes instrumentales. L’interface utilisateur, écrite en JAVA, ne contient aucune intelligence d’instrumentation, mais elle rassemble l’ensemble des méthodes nécessaires à l’utilisateur pour interagir et conduire son expérience. La bibliothèque CORBA connecte le serveur au client, ils peuvent s’exécuter sur le même ordinateur ou sur des machines différentes. Tous les instruments partagent le même code, mais un ensemble de fichiers XML permettent de configurer le serveur NOMAD, et ainsi d’adapter l’ensemble des contrôleurs hardware et des méthodes instrumentales aux besoins spécifiques de chaque expérience. Le serveur dispose d’un outil qui ordonnance, au moyen de « multithreads », l’exécution en parallèle de différentes taches. L’interface graphique permet aux utilisateurs de créer intuitivement, à l’aide de « drag-and-drop », l’ensemble des séquences spécifiques qui constituent le scénario de leur expérience, ils ont à leur disposition la vue sur les opérations passées présentes et futures. Le serveur de NOMAD contient également une grande diversité de modules pour contrôler l’environnement de l’échantillon. Tous ses équipements spécifiques sont configurables et paramétrables directement via l’interface graphique. L’intégration complète du contrôle de l’environnement et des méthodes scientifiques, via notre séquenceur, permet aux scientifiques de mieux synchroniser, gérer les événements, et optimiser leurs expériences.

Un ingénieur informatique SCI est en charge du développement des composants logiciels de NOMAD serveur et client. Il doit gérer au quotidien, l’ensemble des interventions sur les instruments dont il a la responsabilité (5 à 10 par personne). Les expériences se déroulent 24h/24 pendant les 50 jours du cycle réacteur et la forte demande pour nos instruments exige une grande fiabilité et des temps d’intervention minimale. La seconde partie de son activité consiste en un travail d’instrumentaliste. Durant les périodes d’arrêt du réacteur, il devra valider les nouvelles composantes matérielles de l’instrument ainsi que les diverses fonctionnalités propres à celui-ci. Il doit également mettre au point avec le personnel scientifique de l’institut de nouvelles méthodes de contrôle ou d’optimisation, qui permettront à nos visiteurs une prise en main toujours plus aisée de nos instruments.

Dans un prochain article, nous détaillerons le fonctionnement de NOMAD.

Franck CECILLON, Paolo MUTTI

n°17
Juillet
2011
Rencontres LCG-France 2011 (session de printemps)

LCG-France organise depuis maintenant plus de six ans deux rencontres par an au cours desquelles sont discutés l’état d’avancement du projet, l’évolution de l’infrastructure des sites et les activités de calcul des expériences LHC.

Les 30 et 31 mai derniers, la session de printemps 2011 s’est tenue pour la première fois à l’IPHC (Institut Pluridisciplinaire Hubert Currien) à Strasbourg et a réuni une cinquantaine de personnes (voir le programme).

Le responsable du projet WLCG (Worldwide LHC Computing Grid), Ian Bird, avait fait le déplacement à Strasbourg afin de présenter les perspectives d’évolution du calcul LHC dans les années à venir. Il a tout d’abord tenu à souligner l’efficacité de la grille WLCG, qui est en mesure d’absorber les flux de données du LHC, en particulier au Tier 0 (au CERN) où plus d’un pétaoctet de données est déposé ou lu par jour. Au niveau mondial, c’est plus d’un million de tâches de calcul qui sont exécutées par jour sur près de 150 000 processeurs. La grille LCG, qui était il y a une dizaine d’années un projet expérimental, est aujourd’hui une machine puissante et pleinement opérationnelle. Les défis de la gestion et de l’accès intensif aux données, la cohabitation des activités d’analyse utilisateur avec les productions centralisées ont été relevés. Mais l’effort nécessaire de la part des administrateurs de sites et des équipes chargées du suivi des opérations reste encore important.

La montée en puissance et la fiabilité du réseau sont une réalité qui n’avait pas été pleinement prévue lors de la conception des grilles de calcul. Ces performances permettent d’envisager un usage beaucoup plus souple des données distribuées et totalement interconnectées. La présence de Dany Vandromme et de Xavier Jeannin de RENATER a permis d’aborder la question de l’évolution de la connectivité réseau autour d’une architecture prototype baptisée LHCONE (pour LHC Open Network Environnement) et qui, à terme, renforcerait la connectivité de l’ensemble des sites. D’autres évolutions majeures se profilent, comme le calcul en nuage et la virtualisation qui l’accompagne. Il s’agit là de nouveaux défis à relever pour les sites comme pour les expériences. L’infrastructure de grille et de stockage WLCG telle qu’on la connaît sera sans doute amenée à évoluer vers un modèle moins spécifique que celui mis en œuvre actuellement, répondant mieux aux besoins de gestion de données distribuées, intégrant des standards en usage sur d’autres systèmes et d’autres modèles distribués.

Dominique Boutigny, directeur du CC-IN2P3 et Vincent Breton, responsable de France Grilles, ont également évoqué les perspectives offertes par les technologies de « Cloud » pour enrichir l’infrastructure actuelle. Des cas d’utilisation dans le contexte du calcul LHC existent. Nul doute que la réflexion va se poursuivre à une cadence soutenue, portée par les événements et échéances à venir : la conférence annuelle WLCG à DESY et la seconde vague EQUIPEX notamment.

Une session est traditionnellement consacrée aux rapports d’avancements des sites. Le LPSC de Grenoble, qui demande à passer T2 pour Atlas et Alice, a présenté un projet pertinent au regard de l’évolution de ses capacités et de la qualité de son infrastructure. La diversification des utilisateurs est dans ce site, comme ailleurs, un signe que le calcul sur grille répond également aux besoins d’autres communautés scientifiques, notamment ceux de la VO "mure" pour la simulation des réacteurs nucléaires, ainsi que de nombreux domaines de recherche regroupés au niveau régional sous le label idgrilles.

Yannick PATOIS

n°17
Juillet
2011
Premières rencontres scientifiques GIS France Grille

Le 19 septembre 2011, à Lyon

Le GIS France Grilles organise ses premières rencontres scientifiques.
Elles se tiendront à Lyon, la veille de la première journée de l’ ’EGI Technical Forum 2011’, soit le 19 septembre 2011.

L’objectif de ces premières rencontres est de présenter un panorama des travaux scientifiques, dans toutes les disciplines, réalisés avec l’apport des grilles de production ou grâce à ces grilles.
Le comité scientifique des rencontres de France Grilles décernera à l’occasion de ces journées le premier prix France Grilles pour la contribution la plus marquante.

Pour toute information complémentaire, n’hésitez pas :
à consulter le site web http://france-grilles-2011.sciencesconf.org/
ou
à contacter le comité de programme par mail : cp-rencontresfg2011-l@FRANCE-GRILLES.FR

ACAT 2011

Le 5 Septembre 2011, à Uxbridge

Le 14ème Workshop international ACAT (Advanced Computing and Analysis Techniques in Physics Research) se tiendra le 5 Septembre prochain à Uxbridge (London-UK), sur le campus de l’Université Brunel.

Pour plus d’information concernant cet évènement, veuillez consulter le site ACAT 2011.

JDEV2011 : Journées nationales sur le développement logiciel dans la Recherche et l’Enseignement Supérieur

29 et 30 Septembre 2011, à Toulouse

Les objectifs de ces journées nationales sont les suivants :

  • Etablir un premier contact entre les développeurs de logiciel
  • Connaître, discuter, débattre de nos activités autour du développement scientifique
  • Organiser une communauté autour de thèmes de réflexion sous forme de groupes de travail
  • Diffuser nos connaissances, partager nos expériences

Ces journées se dérouleront dans les locaux de l’ENSEEIHT.

Contact : JDEV2011-contact@laas.fr

EGI Technical Forum 2011

19 au 23 septembre, à Lyon

Le plus grand événement européen sur les grilles informatiques, l’EGI Technical Forum, se déroule cette année à Lyon, du 19 au 23 septembre 2011.

Cette conférence prévoit de rassembler entre 500 et 600 participants, accueillis au Centre de Congrès de Lyon : un site moderne et récent, lieu unique en Europe, offrant des équipements de dernière génération et idéalement situé dans un cadre agréable, entre Rhône et Parc de la Tête d’Or, à proximité immédiate de la ville.

Co-organisé par le Centre de Calcul de l’IN2P3 / CNRS, le Groupement d’Intérêt Scientifique France Grilles et l’initiative de grille en Europe EGI.eu, le EGI Technical Forum est la conférence annuelle qui rassemble les acteurs de l’infrastructure de grille EGI en Europe.

Vous pouvez vous inscrire, et trouver toutes les informations sur le Technical Forum et les événement co-localisés, en cliquant sur le programme.

Workshop NARVAL

Du 17 au 21 Octobre, IPN Orsay

Narval est un environnement de travail, dont le coeur est écrit en Ada 2005, et qui permet d’écrire des systèmes d’acquisition.

Pour plus d’information, voir le site de l’école ou contacter Luz Guevara