imprimer
n°16
Mai
2011
Déploiement du nouveau système de batch au Centre de Calcul : Grid Engine prend le relais de BQS !
Comme évoqué dans la lettre n° 11 de mai 2010, le Centre de Calcul a décidé d’abandonner son système de batch historique « BQS » au profit du logiciel « Grid Engine ». Depuis presque un an, date à laquelle le choix de Grid Engine (GE) a été entériné, le Centre de Calcul travaille activement au remplacement du système de batch. Le choix s’est porté sur la version open source de Grid Engine (6.2 update 5), choix motivé par notre volonté d’adapter le logiciel à nos besoins, en dehors de tout support commercial.

Chronologiquement, le travail a commencé par une exploration exhaustive des fonctionnalités du produit. Cette expertise a permis de mettre en place une formation interne, initialement auprès d’un groupe de travail restreint, puis dans un deuxième temps à toute personne du CC.

Parallèlement, un premier cluster dit de développement été configuré afin de permettre la mise au point des ‘hooks’ d’adaptation à nos besoins. La gestion des tokens AFS, la régulation des flux de jobs, le contrôle de l’espace disque consommé, le traitement des jobs parallèles, l’adaptation à la grille de calcul (computing element) sont quelques uns des chantiers que nous avons dû traiter. Le mot « chantier » exprime bien l’investissement que chaque point a nécessité au regard des (...)

lire la suite

Système d'acquisition

Un système d’acquisition pour Spiral2

Les détecteurs autour de SPIRAL2, le nouvel accélérateur en construction au GANIL, sont à différent stades de conception, certains à l’étape de projet, d’autres au stade de démonstrateur (ex. : AGATA). Au sein du comité de coordination pour l’instrumentation de SPIRAL2, un groupe de travail, composé de membres de chacune des collaborations et de représentants du GANIL, a été chargé de considérer les problèmes liés à l’acquisition de données, de recommander des solutions et, si besoin, de définir des standards pour le développement des logiciels d’acquisition de ces instruments. Cet article résume les premières recommandations de ce groupe de travail. Un rapport complet est en cours d’écriture. Définition de la problématique La problématique est d’intégrer dans le système d’acquisition de GANIL-SPIRAL2 ces ensembles de détection de plusieurs milliers de voies chacun, construits dans différents laboratoires, destinés pour certains uniquement à SPIRAL2, mais pour d’autres appelés à voyager auprès de différents accélérateurs. Ces instruments complexes doivent pouvoir être couplés (...)

lire la suite

Virtualisation

Cloud Computing : suivez le guide !

Il y a presque 15 ans, lors d’une conférence à Dallas, le Pr R. K. Chellappa inaugura le terme de Cloud Computing. Il le présentait alors comme "a new computing paradigm where the boundaries of computing will be determined by economic rationale rather than technical limits alone" (Pr Chellappa R. K., Intermediaries in Cloud-Computing, Dallas, 1997). Aujourd’hui, le Cloud Computing est synonyme d’externalisation des données et traitements informatiques de l’infrastructure locale vers des serveurs distants, auxquels l’utilisateur accède par le réseau, quelque soit leur emplacement dans la « nébuleuse » Internet (le cloud). A l’instar de l’électricité qui est disponible depuis la prise de courant peu importe son lieu de production ou son origine nucléaire, éolienne... Nombre d’entre nous utilise déjà des applications de Cloud Computing ; l’exemple le plus évident étant celui des messageries en ligne. Parmi les leaders du domaine : Google et ses outils de bureautique en ligne (Google Apps) - http://www.google.com/apps, Amazon et ses Web Services (AWS) - aws.amazon.com. (...)

lire la suite

Grand instrument

L’IN2P3 participe au défi scientifique du LSST

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. En particulier, l’IN2P3 est responsable du logiciel de contrôle commande de la caméra, le CCS. Ce premier article présente le projet LSST, puis dans la prochaine édition de la Lettre IN2P3, un article donnera les points forts du cahier des charges du CCS, décrira l’architecture générale, et expliquera les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java. Le Télescope LSST, Large Synoptic Survey Telescope, (http://lsst.in2p3.fr) sera installé au Cerro Pachón, près de La Serena au Chili, en 2018. Il est actuellement en cours de conception aux États-Unis et en France. Ce télescope, de très large ouverture (10 degrés carrés) intègre une caméra CCD de 3,2 Gpixels et un miroir principal de 8,4 m de diamètre. Il photographiera les objets célestes de faible luminosité dans six longueurs d’onde dans le domaine du visible. Il effectuera un balayage systématique du ciel en trois nuits à raison de deux poses de 15 secondes pour chaque parcelle du ciel. (...)

lire la suite

Actualités

Japon : des nouvelles de nos collègues

Le 11 mars dernier, le Japon était touché par l’un des séismes les plus puissants que le monde moderne ait connu, bientôt suivi par un tsunami qui a ravagé la côte nord-est avec les conséquences dramatiques que l’on sait. Au-delà du drame humain, la communauté scientifique française s’est émue du sort des collègues japonais ou immigrés qui se trouvaient sur place lors du désastre. En effet, de très nombreuses collaborations scientifiques lient le Japon et la France, et comme souvent, au-delà des projets et des réalisations, ces échanges s’enrichissent de contacts humains qui dépassent les simples relations de travail. L’IN2P3 et le Japon collaborent notamment dans le cadre du Laboratoire International Associé Toshiko Yuasa (ex FJPPL) et plus spécifiquement sur un projet autour des grilles de calcul qui lie le centre de calcul de KEK et le CC-IN2P3. Dès le 11 mars le CC-IN2P3 a reçu des nouvelles de Damien Mercier ancien du groupe support (CMS) installé depuis peu au Japon près de Tokyo ; celui-ci nous rassurait et semblait même surpris de l’ampleur de la couverture (...)

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

A noter
Failles de sécurité dans SPIP : installez SPIP 2.1.10 !
De nombreux sites Web du domaine IN2P3 utilisent le système de publication SPIP. Plusieurs (...)

en savoir plus

Agenda
Réunion LCG-France, à l’IPHC
Cette réunion bi-annuelle, organisée par LCG-France, permet une rencontre des différents sites où (...)

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

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°16
Mai
2011
Déploiement du nouveau système de batch au Centre de Calcul : Grid Engine prend le relais de BQS !

Calcul

Comme évoqué dans la lettre n° 11 de mai 2010, le Centre de Calcul a décidé d’abandonner son système de batch historique « BQS » au profit du logiciel « Grid Engine ».

Depuis presque un an, date à laquelle le choix de Grid Engine (GE) a été entériné, le Centre de Calcul travaille activement au remplacement du système de batch. Le choix s’est porté sur la version open source de Grid Engine (6.2 update 5), choix motivé par notre volonté d’adapter le logiciel à nos besoins, en dehors de tout support commercial.

Chronologiquement, le travail a commencé par une exploration exhaustive des fonctionnalités du produit. Cette expertise a permis de mettre en place une formation interne, initialement auprès d’un groupe de travail restreint, puis dans un deuxième temps à toute personne du CC.

Parallèlement, un premier cluster dit de développement été configuré afin de permettre la mise au point des ‘hooks’ d’adaptation à nos besoins. La gestion des tokens AFS, la régulation des flux de jobs, le contrôle de l’espace disque consommé, le traitement des jobs parallèles, l’adaptation à la grille de calcul (computing element) sont quelques uns des chantiers que nous avons dû traiter. Le mot « chantier » exprime bien l’investissement que chaque point a nécessité au regard des services impliqués et impactés. En effet, la mise en œuvre d’un nouveau système de batch consiste aussi à trouver le meilleur équilibre entre les méthodes de travail existantes et validées au cours du temps et de nouvelles possibilités offertes par le produit.

Au cours de l’automne 2010, un nouveau cluster dit de pré-production a été installé. Il intégrait les premières adaptations réalisées. La finalité de ce cluster était de permettre à des utilisateurs volontaires d’adapter leur production de calculs au nouveau système. L’intérêt était de bénéficier de leur retour d’expérience pour valider nos choix et adaptations réalisées. Leur aide a été très précieuse et nous les remercions vivement pour leur implication.

Au delà des adaptations fonctionnelles, nous avons entrepris de nombreux tests. Une première phase, démarrée en octobre 2010, avait pour but de définir les contours de notre installation (serveurs, base de données, système de fichiers, réseau, etc) et d’affiner notre compréhension du produit. Ces essais nous ont aussi permis de confirmer notre intuition quant à la qualité du logiciel, comme le montre l’exemple suivant (fig 1).

Une deuxième phase de tests a été conduite au cours du premier trimestre 2011. Elle avait pour but de valider la configuration et de prédire, aussi précisément que possible, le comportement du produit avec une charge de traitement la plus proche de la production réelle. Parmi les essais réalisés, nous avons soumis l’intégralité de la « machinerie batch » à un flux de jobs intensif et permanent avec plus de 50.000 jobs traités /heure, sur une période de 72h (fig 2).

Ces essais n’ont révélé ni dysfonctionnement, ni point de contention, que ce soit du coté des serveurs, que de celui des codes d’adaptation à nos spécificités. Avec Grid Engine, nous pourrons aborder sereinement les demandes de calcul toujours croissantes. Pour mémoire, nous traitons actuellement 13.000 jobs simultanément et un flux d’environ 100.000 jobs/jour. Mais la mise en production imminente de la nouvelle salle machine va largement amplifier ces chiffres, et bien que le système de batch actuel, BQS, affiche un excellent comportement, il convient, en informatique comme ailleurs, de toujours garder une longueur d’avance sur les demandes des utilisateurs.

L’ouverture en production du cluster Grid Engine est prévue au cours du mois de mai 2011, avec comme objectif le basculement complet de BQS vers Grid Engine avant la fin de l’année. Ainsi 2011 s’achèverait par l’arrêt définitif de notre système de batch historique, après 18 ans de « bons et loyaux services » : Bonne retraite BQS !

Bernard CHAMBON

n°16
Mai
2011
Cristinel Diaconu : « Le CCRI a trouvé sa place au sein du réseau »

Chargé de mission à l’informatique à l’IN2P3

La dernière réunion annuelle des responsables de service informatique a eu lieu le 28 février au Centre de Calcul de l’IN2P3. Cristinel Diaconu, chargé de mission à l’informatique à l’IN2P3, revient sur cette réunion.

- Quel est l’objectif de la réunion des responsables de services informatique ?

Les responsables de service informatique se réunissent tous les ans, généralement au CC-IN2P3, pendant une journée divisée de la manière suivante : le matin est consacré à une réunion plénière ouverte, où tout le monde peut assister ou se connecter en audioconférence ; l’après-midi est une session fermée, accessible aux seuls chefs de service informatique de l’IN2P3. Au total, une vingtaine de personnes a assisté à la dernière réunion. Ces réunions sont l’occasion de parler des dernières nouveautés, des derniers développements et outils du CC-IN2P3, d’échanger sur les technologies développées au sein du réseau. C’est donc aussi l’occasion d’identifier les outils qui puissent être utiles aux laboratoires.

-  Quels sont les sujets qui ont été abordés ?

Il y a eu plusieurs présentations en session ouverte, notamment sur une étude des performances des file systèmes partagés hébergeant les softs des expériences, les projets Active Directory et Plume, les Outils collaboratifs, etc. Une visite des installations du CC-IN2P3 a également eu lieu l’après-midi. Si on prend Active Directory par exemple, on peut dire que ce qui est ressorti des discussions est que c’est un projet efficace, avec peu de participants et pourtant beaucoup d’utilisateurs et donc un gros impact à l’IN2P3. On devrait d’ailleurs à mon sens peut-être mettre plus de ressources sur ce projet. C ‘est le cas pour d’autre projets multi-laboratoire (Forge, Nomadisme, Webinaires etc.), qui ont le potentiel de renforcer la visibilité de l ‘IN2P3 et d’augmenter l’échange de compétences entre les services informatiques. Un sondage effectué récemment dans les laboratoires révèle une multitude d’idées nouvelles concernant des possibles projets communs possible grâce aux compétences et aux besoins communs des laboratoires de l’IN2P3 et de l’IRFU. Le réseau RI3* et son conseil de coordination (CCRI) sont le cadre idéal pour développer ce genre de projets. Il faut trouver également les moyens adéquats et continuer la communication au sein de réseau. A suivre…

-  Peut-on vous demander ce qui a été discuté en session fermée ?

La discussion se concentre autour des sujets d’actualité dans les services. Sans trop dévoiler de choses, on peut quand même dire qu’il y a eu par exemple des discussions sur le fait qu’on devrait rendre les services informatiques plus visibles. On a par exemple envisagé d’établir un catalogue de compétences afin de mettre en valeur les compétences informatiques au niveau de l’IN2P3. Evidemment, on a également parlé prospective, perspective pluriannuelle.

-  Que retenez-vous de cette journée ?

Hormis ce que j’ai déjà dit, j’ai trouvé que le Conseil de Coordination du Réseau des Informaticiens de l’IN2P3 (CCRI) avait trouvé sa place au sein du RI3*. Je suis très satisfait de voir qu’il est maintenant intégré dans la façon de fonctionner des informaticiens. Nous sommes d’ailleurs en plein discussion sur le renouvellement du CCRI. Les nouveaux membres devraient bientôt être nommés.

* Réseau des informaticiens de l’IN2P3 et de l’IRFU.

PROPOS RECUEILLIS PAR G.S.

n°16
Mai
2011
Un système d’acquisition pour Spiral2

Les détecteurs autour de SPIRAL2, le nouvel accélérateur en construction au GANIL, sont à différent stades de conception, certains à l’étape de projet, d’autres au stade de démonstrateur (ex. : AGATA). Au sein du comité de coordination pour l’instrumentation de SPIRAL2, un groupe de travail, composé de membres de chacune des collaborations et de représentants du GANIL, a été chargé de considérer les problèmes liés à l’acquisition de données, de recommander des solutions et, si besoin, de définir des standards pour le développement des logiciels d’acquisition de ces instruments. Cet article résume les premières recommandations de ce groupe de travail. Un rapport complet est en cours d’écriture.

Définition de la problématique

La problématique est d’intégrer dans le système d’acquisition de GANIL-SPIRAL2 ces ensembles de détection de plusieurs milliers de voies chacun, construits dans différents laboratoires, destinés pour certains uniquement à SPIRAL2, mais pour d’autres appelés à voyager auprès de différents accélérateurs. Ces instruments complexes doivent pouvoir être couplés afin de constituer un super instrument. Les recommandations doivent donc permettre une grande modularité et simplifier l’association de ces instruments tant du point de vue commande et contrôle que du point de vue des flux de données.

Le système proposé est basé sur une architecture client serveur avec pour principales composantes :

  1. le contrôle de l’électronique (Electronics Control),
  2. le flux de données assurant le transport et le traitement des données des modules électroniques jusqu’au stockage
  3. le contrôle de l’ensemble du système (Global Run Control) pendant les expériences.

L’ « Electronics Control » est une application en charge du contrôle complet du matériel. C’est une application client/serveur qui communique d’une part avec les différentes cartes électronique et d’autre part avec des clients tels qu’une interface homme-machine ou le « Global Run Control ».

Le flux de données est construit à partir du système NARVAL, développé à l’origine par X. Grave (IPN Orsay). Ce système assure le transport de données entre différents acteurs pouvant être répartis sur différentes machines, par simple description d’une topologie par un fichier XML. Son concept modulaire permet d’intégrer facilement dans le flux de données les acteurs nécessaires au filtrage et à la reconstruction des événements. L’analyse en ligne se fait entre autre via un process externe client d’un des acteurs. Le GANIL propose de réaliser ces programmes d’analyse, spécifiques à chaque expérience, avec GRU (GANIL ROOT Utilities) et Vigru (Visualisation GRU), des outils largement basés sur ROOT.

Le « Global Run Control » (GRCC), basé sur les mêmes paradigmes client/serveur, est associé à une interface graphique cliente, et est le poste de pilotage de l’expérience. Il coordonne les différentes activités nécessaires pour mettre le système en état de fonctionnement. Il interagit avec le ou les process « Electronics Control » pour initialiser l’électronique avant la prise de données. Il fournit également les outils de contrôle, de report d’alarmes et de journalisation pour l’ensemble du système. Il a été conçu pour être évolutif et pour contrôler les systèmes des différents instruments construits par les collaborations. Pour cette raison, il est construit autour du concept de gestionnaire d’instruments.

Les échanges de commandes entre GRCC et les applications de contrôle de l’électronique, se font par l’intermédiaire de services WEB utilisant le protocole SOAP. La journalisation des messages et la propagation des alarmes se fait via log4Cxx initialement développé en Java, disponible pour différents langages (Java, C++, ADA,…).

Recommandations

Un certain nombre de recommandations ont été définies par le groupe de travail, afin de faciliter l’intégration des équipements dans le système d’acquisition de GANIL-SPIRAL2. On peut citer en particulier les points suivants :

  • Pour pouvoir être contrôlées par le « Global Run Control », les applications d’ « Electronics Control » devront répondre à un lot minimum de commandes SOAP et respecter une machine d’état décrits dans un document de référence. Les mécanismes log4Cxx devront être utilisés pour la journalisation des messages et la propagation des alarmes.
  • Une spécification de format de données commun a été adoptée, le MultiFrame Metatformat (MFM), basé sur un concept de multi-frames permettant de définir des formats binaires autosuffisants, en couche, adaptés au transfert réseau et évolutifs. Cette spécification autorise une description complète de tout type de données, y compris l’encapsulation de format de données autres. Il est recommandé pour les nouveaux instruments d’adopter ce format de données à la construction.

Le système d’acquisition standard actuellement en exploitation au GANIL est entièrement basé sur cette architecture et sert de banc d’expérimentation grandeur réel. Il a déjà permis d’intégrer et de coupler avec succès différents systèmes grâce à sa conception entièrement modulaire. Les débits de données actuellement traitées sont de l’ordre de quelques Moctets/sec. Reste à transformer l’essai avec des systèmes plus complexes et demandant des performances d’acquisition de plusieurs centaines de Moctets/sec. L’infrastructure réseau ainsi que les capacités de stockage devront être adaptées à de telles quantités de données. Les premières expériences sont prévues pour début 2014.

Bruno RAINE

n°16
Mai
2011
Cloud Computing : suivez le guide !

Il y a presque 15 ans, lors d’une conférence à Dallas, le Pr R. K. Chellappa inaugura le terme de Cloud Computing. Il le présentait alors comme "a new computing paradigm where the boundaries of computing will be determined by economic rationale rather than technical limits alone" (Pr Chellappa R. K., Intermediaries in Cloud-Computing, Dallas, 1997).

Aujourd’hui, le Cloud Computing est synonyme d’externalisation des données et traitements informatiques de l’infrastructure locale vers des serveurs distants, auxquels l’utilisateur accède par le réseau, quelque soit leur emplacement dans la « nébuleuse » Internet (le cloud). A l’instar de l’électricité qui est disponible depuis la prise de courant peu importe son lieu de production ou son origine nucléaire, éolienne... Nombre d’entre nous utilise déjà des applications de Cloud Computing ; l’exemple le plus évident étant celui des messageries en ligne.

Parmi les leaders du domaine : Google et ses outils de bureautique en ligne (Google Apps) - http://www.google.com/apps, Amazon et ses Web Services (AWS) - aws.amazon.com. Lancé en février 2007, Google Apps comptait pour l’année 2009-2010, 5 millions d’étudiants utilisant activement son Education Edition. Il y aurait aujourd’hui 3 millions d’entreprises clientes des Google Apps for Business, dont plus d’un million en Europe. En août 2006, Amazon ouvrait l’accès à son infrastructure de Cloud. En mars 2010, son service de stockage en ligne hébergeait plus de 102 milliards de fichiers contre 52 milliards un an plus tôt, où les activités Cloud Computing du groupe représentaient moins de 3% de son chiffre d’affaire.

La promesse de cette technologie pour le client : un accès au service à la demande et potentiellement illimité, sans coût d’investissement supplémentaire (matériel, licence, expertise, maintenance). Il paie uniquement ce qu’il consomme. L’administrateur de Cloud lui garantit la qualité et la continuité d’un service accessible depuis une simple application Web. Le nerf du Cloud Computing c’est le réseau, dont on exige rapidité, fiabilité et disponibilité. La stratégie, qui constite à s’appuyer sur des solutions existantes (TPC/IP, SOA, informatique distribuée, virtualisation), permet en principe de réduire les développements nécessaires à la mise en œuvre du Cloud Computing.

Le partage des ressources informatiques, à l’origine de la mise en place de la grille européenne (actuelle EGI) au début des années 2000, est également au cœur du concept de Cloud Computing. Migrer la grille sur le Cloud serait donc une suite logique, du moins selon le point de vue du projet StratusLab (stratuslab.eu) démarré en juin 2010. Son objectif est de fournir une solution complète pour installer, administrer et contrôler une infrastructure de calcul distribué virtualisée. La grille, forte de ses modèles de sécurité et de fédération des ressources déjà éprouvés, bénéficiera ainsi de la simplicité et de la flexibilité caractéristiques des Clouds. L’utilisateur pourra développer son environnement d’exécution personnalisé sous forme d’images déployables sur les nœuds virtuels et partageables au sein d’un marketplace. Et l’administrateur grille pourra adapter en temps réel la taille de son site (puissance de calcul et stockage) aux besoins des utilisateurs. A terme, c’est la construction d’une grille souple, facile à implémenter et donc plus attractive auprès des communautés scientifique et industrielle.

Le Cloud Computing présente de nombreux atouts. Mais il soulève aussi bien des objections concernant la nécessité de standardisation des interfaces, la perte de maîtrise pour le client, la forte dépendance au réseau, la pérennité des solutions Cloud. Et le véritable point sensible reste la sécurité : la protection des données hébergées, les possibilités d’utilisation abusive par les spammeurs ou les pirates informatiques... Autant d’interrogations auxquelles les fournisseurs de Cloud devront apporter des réponses satisfaisantes s’ils ne veulent pas voir le soufflé marketing retomber.

Christelle ELOTO

n°16
Mai
2011
L’IN2P3 participe au défi scientifique du LSST

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. En particulier, l’IN2P3 est responsable du logiciel de contrôle commande de la caméra, le CCS. Ce premier article présente le projet LSST, puis dans la prochaine édition de la Lettre IN2P3, un article donnera les points forts du cahier des charges du CCS, décrira l’architecture générale, et expliquera les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java.

Le Télescope LSST, Large Synoptic Survey Telescope, (http://lsst.in2p3.fr) sera installé au Cerro Pachón, près de La Serena au Chili, en 2018. Il est actuellement en cours de conception aux États-Unis et en France. Ce télescope, de très large ouverture (10 degrés carrés) intègre une caméra CCD de 3,2 Gpixels et un miroir principal de 8,4 m de diamètre. Il photographiera les objets célestes de faible luminosité dans six longueurs d’onde dans le domaine du visible. Il effectuera un balayage systématique du ciel en trois nuits à raison de deux poses de 15 secondes pour chaque parcelle du ciel. Il recueillera ainsi 15 To de données par nuit, un volume de même grandeur que celui du LHC.

Un des enjeux scientifiques de ce télescope pour l’IN2P3, outre la cartographie des galaxies, est de caractériser l’équation d’état de l’énergie noire.

Ce projet est un projet international de financement public-privé. Les fonds publics américains viennent de la NSF et la DOE et en France, il est financé par le CNRS via l’IN2P3.

C’est un très grand instrument du CNRS et le « Committee for a Decadal Survey of Astronomy » aux États-Unis l’a classé en premier sur la liste des projets prioritaires au sol pour les dix prochaines années.

Les responsabilités de l’IN2P3 dans la caméra de LSST

Le projet est piloté par la LSST Corporation (http://www.lsst.org). Il est divisé en trois sous-projets : Telescope, Camera, Data Management. Un MOU entre la LSST Corporation et l’IN2P3 a été signé en octobre 2009. Les équipes techniques de l’IN2P3 sont impliquées dans le sous-projet Camera. Sept laboratoires contribuent actuellement à LSST : l’APC, le CC, le LAL, le LMA, le LPNHE, le LPSC et le CPPM.

Le responsable scientifique est Pierre Antilogus, du LPNHE et le responsable technique est Christophe Vescovi du LPSC. Notre contribution couvre les trois domaines de la mécanique, l’électronique et l’informatique.

La mécanique

L’IN2P3 est responsable de la conception et du développement du système d’échangeur de filtres de la caméra.

Puisque la collaboration a besoin d’images dans six bandes photométriques, la caméra est équipée de six filtres. Cinq d’entre eux pourront loger autour de la caméra, suspendus à un carrousel qui tourne autour de la caméra. Un sixième filtre sera en réserve dans un changeur manuel et pourra être introduit dans la caméra à la demande. Un système mécanique appelé « auto-changeur » permettra de venir saisir un filtre sur le carrousel pour venir le mettre devant l’objectif.

L’électronique

En électronique, l’IN2P3 est impliqué du développement de l’électronique front-end des CCD jusqu’au banc de caractérisation de la caméra CCD.

L’informatique (contrôle commande)

En informatique, l’IN2P3 a en charge la conception et le développement du logiciel de contrôle commande de la caméra (CCS : Camera Control System) et de l’échangeur de filtres (FCS : Filter exChanger System).

Le logiciel de contrôle commande de la caméra : le CCS

Le projet Camera 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.

Le CCS n’est pas un système d’acquisition de données, 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 d’environnement

Du fait que ce logiciel ne gère pas le flot de données, il n’y a pas de contraintes « temps réel dur », 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 impose d’une part une grande qualité dans l’écriture de la documentation technique et utilisateur et du code, 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.

Rendez-vous dans la prochaine lettre informatique pour une description du CCS et des choix techniques effectués.

Éric AUBOURG, Françoise VIRIEUX

n°16
Mai
2011
Japon : des nouvelles de nos collègues
Laboratoire International Associé Toshiko Yuasa

Le 11 mars dernier, le Japon était touché par l’un des séismes les plus puissants que le monde moderne ait connu, bientôt suivi par un tsunami qui a ravagé la côte nord-est avec les conséquences dramatiques que l’on sait. Au-delà du drame humain, la communauté scientifique française s’est émue du sort des collègues japonais ou immigrés qui se trouvaient sur place lors du désastre. En effet, de très nombreuses collaborations scientifiques lient le Japon et la France, et comme souvent, au-delà des projets et des réalisations, ces échanges s’enrichissent de contacts humains qui dépassent les simples relations de travail.

L’IN2P3 et le Japon collaborent notamment dans le cadre du Laboratoire International Associé Toshiko Yuasa (ex FJPPL) et plus spécifiquement sur un projet autour des grilles de calcul qui lie le centre de calcul de KEK et le CC-IN2P3.

Dès le 11 mars le CC-IN2P3 a reçu des nouvelles de Damien Mercier ancien du groupe support (CMS) installé depuis peu au Japon près de Tokyo ; celui-ci nous rassurait et semblait même surpris de l’ampleur de la couverture médiatique de l’évènement en France. Il était en tout cas frappé par la qualité des constructions anti-sismiques à Tokyo et par l’efficacité de l’organisation du pays.

Nous sommes restés sans nouvelles de KEK jusqu’au 14 mars en raison des pannes des réseaux électriques et de téléphonie mobile. Finalement nous avons été rassurés par notre collègue Takashi Sasaki puisqu’aucune victime n’était à déplorer, ni à KEK ni sur le site voisin de Tokai. Les dégâts matériel étaient et demeurent significatifs mais restent heureusement dans le domaine du réparable. Les lignes de faisceaux ultra-précises ont été bien évidemment particulièrement bousculées (voir : http://www.kek.jp/intra-e/press/2011/PFRecoveryProspects.html)

Le mail et le serveur web de KEK ont été les équipements informatiques les plus prompts à revenir en ligne, ce qui a d’ailleurs permis à KEK de publier très tôt des mesures de radioactivité régulières et indépendantes des organismes officiels (voir : www.kek.jp/quake/radmonitor/index-e.html).

Le problème principal aujourd’hui pour l’ensemble du site de KEK réside dans la pénurie d’électricité qui impacte fortement l’ensemble du pays. Fin mars, le directeur du centre de calcul de KEK, Mitsuaki Nozaki m’informait que KEK devait fonctionner avec une puissance réduite à 10 à 20% de la normale, limitant fortement le centre de calcul. Dans ces conditions l’analyse des données de l’expérience Belle s’est trouvée bloquée, conduisant la collaboration Belle à redéployer ses données et son analyse sur les autres sites de la collaboration. Soutenu par Jacques Martino, le CC-IN2P3 a offert des moyens informatiques à la collaboration Belle, ceux-ci seront utilisés si les ressources internes s’avèrent insuffisante. Il est évident que face à de telles difficultés l’entraide scientifique doit jouer à plein.

Conséquence inattendue de la situation au Japon, les dernières machines DELL qui doivent être livrées au CC-IN2P3 risquent de prendre du retard en raison de problème d’approvisionnement au niveau des alimentations électriques d’origine japonaises. Ceci est évidemment dérisoire face au drame humain, mais illustre à quel point l’économie du pays tout entier est impactée.

Dominique BOUTIGNY

n°16
Mai
2011
Réunion LCG-France, à l’IPHC

30 et 31 Mai 2011

Cette réunion bi-annuelle, organisée par LCG-France, permet une rencontre des différents sites où les infrastructures WLCG et LCG-France, leur fonctionnement et les solutions pour améliorer le calcul pour les expériences LHC, sont discutés. La session de printemps 2011 se tiendra à Strasbourg, à l’IPHC les 30 et 31 mai. Voir le programme de cette rencontre

NB : les inscriptions sont ouvertes jusqu’au 25 Mai.

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

Vous serez informés prochainement de la procédure d’inscription.

Contact : JDEV2011-contact@laas.fr

n°16
Mai
2011
ADONIS recrute à Lyon et Orléans

Ingénieurs en informatique scientifique et ingénieurs en édition électronique et gestion de projets numériques.

Pour renforcer ses équipes, le TGE Adonis recrute des ingénieurs d’études sur des contrats de longue durée (2 ans) .

Vous trouverez tous les détails des postes proposés sur le site d’ADONIS.

Postes d’Ingénieur d’Études développeur en Contrôle-Commande (LULI - Ecole Polytechnique de Palaiseau)

Deux postes (CDD) d’Ingénieur d’Etudes sont à pourvoir sur le site de l’Ecole Polytechnique de Palaiseau (91).

Vous trouverez le détail des deux postes proposés en cliquant sur ce lien.

n°16
Mai
2011
Failles de sécurité dans SPIP : installez SPIP 2.1.10 !

A noter

De nombreux sites Web du domaine IN2P3 utilisent le système de publication SPIP. Plusieurs alertes de sécurité SPIP ont été récemment émises par différents canaux.

Il est fortement conseillé d’installer l’écran de sécutité sur tous les sites SPIP, et de faire évoluer ces derniers vers la dernière version SPIP 2.1.10 corrigeant ces failles.

Pour plus d’information sur ces mises à jour de sécurité, veuillez consulter le site SPIP-Contrib .