1 Stéphane JEZEQUEL 23 Juin 2008 Analyse des données LHC dans ATLAS S. Jézéquel

2 Stéphane JEZEQUEL 23 Juin 2008 Plan Objectifs scientifiques de l'expérience ATLAS au LHC Démarrage prévu à l'automne 2008 Quantité de données et besoin en CPU -> Grille Analyse de données: du traitement centralisé à l'utilisateur

3 Stéphane JEZEQUEL 23 Juin 2008 Accélérateur LHC LHC: Collisionneur de particules de nouvelle génération (proton-proton) Plus haute énergie disponible jamais atteinte (14 TeV:) Produire de nouveaux phénomènes/particules Taux de collision important (25 ns): Nouvelle physique : recherche d'événements rares ( ) Production de particules à chaque collision (multiplicité ~40) -> Taille d'un événement : 1,5 MB

4 Stéphane JEZEQUEL 23 Juin 2008 Objectifs scientifiques : LHC Thématique phare Recherche de la particule Higgs qui est le chainon manquant du 'Modèle Standard' En fonction de sa masse Différents canaux de désintégration privilégiés Différents types et contribution du bruit de fond Construction d'un détecteur multi-canal Higg s

5 Stéphane JEZEQUEL 23 Juin 2008 Détecteur ATLAS Couvre un large spectre de canaux de physique des particules au delà de la recherche du Higgs Responsabilité de groupes de laboratoires (dont LAPP) De définir et construire des parties du détecteur De calibrer ces parties avant et pendant la prise de données Responsabilité de toute la collaboration Reconstruction des particules en combinant les sous-detecteurs Analyse des données à partir des particules reconstruites Rapidité des opérations (concurrence avec autre expérience) Besoins: Calculer et intégrer les données de calibration Mettre rapidement à disposition les données reconstruites et les programmes à tous les membres de la collaboration

6 Stéphane JEZEQUEL 23 Juin 2008 Quantité de données par an Besoin de collecter beaucoup d'événements 'standards' pour calculer les constantes de calibration in-situ pour contrôler les différents bruits de fond ->Ecriture des evts à 200 Hz ( 300 MB/s) ->1 PB de données brutes produites au CERN par an Besoin de processeurs pour les traiter en ligne CERN : 20 % de la puissance disponible (limitation: infrastructure) ->Besoin de ressources informatiques externes Grilles (EGEE/OSG/NorduGrid) : Développement des réseaux géographiques (1-100 Gb/s) -> possibilité de mutualiser les ressources informatiques des laboratoires pour faire les traitements hors-ligne (calibration, analyse) Tests en cours pour faire du monitoring en ligne du détecteur

7 Stéphane JEZEQUEL 23 Juin 2008 Besoins en CPU Calcul scalaire : Chaque job est traité par un seul processeur Pas de correlation entre les jobs ->Maximiser le nombre de processeurs Besoin de coeur avec 2 GB mémoire (description du détecteur) Accès rapide aux données d'entrées

8 Stéphane JEZEQUEL 23 Juin 2008 Applications centralisées Production de masse Simulation d'événements répartie dans le monde entier Fichier de petite taille en entrée Jobs de longue durée (24 heures) Fichiers inputs -> CPU disponibles Se fait dans tous les sites avec des CPU bien configurés (ex : LAPP) Données de sorties réaggregées sur un gros site (ex : CCIN2P3) (transfert asynchrone) Reconstruction et réduction des événements réels/simulés Gros fichiers inputs sur bande (cout du stockage, robustesse) Besoins d'accéder à grande bases de données type Oracle (calibrations) -> Tourne dans les grands centres de calculs (ex : CCIN2P3) Distribution des fichiers vers l'ensemble des sites (ex : LAPP)

9 Stéphane JEZEQUEL 23 Juin 2008 Besoin en CPU: Travail personnel Développement d'algorithme: Se fait sur lot de données copiées localement Validation: Rapide: sur les données Grille stockées localement (ressources CPU ) Plus long sur plus de données: sur l'ensemble des ressources Grille Une fois validé, l'algorithme est intégré à la production centralisée Besoin d'être performant dans l'utilisation des outils Grille Analyse des données réduites: Ressources CPU locales ou PC local/portable (dépend de quantité de données)

10 Stéphane JEZEQUEL 23 Juin 2008 Besoin en réseau Besoin de récupérer les nouvelles données aussi vite que possible (~30-50 TB) Centre distributeur pour LAPP : CCIN2P3 Tests techniques : CCIN2P3 peut délivrer données à 500 Mo/s -> Intérêt d'avoir une liaison dédiée 10 Gb/s CCIN2P3-LAPP

11 Stéphane JEZEQUEL 23 Juin 2008 Soumission de job personnel Utilisateur choisit sa collection de fichiers d'entrée (dataset) et fournit son algorithme Système de soumission choisit parmi les sites ayant: Version de software requise, le dataset demandé, un/plusieurs CPU disponibles Chaque job peut être éclaté en des petits jobs chacun accédant une fraction du dataset (données répliquées sur plusieurs sites) tournant sur des sites différents -> redondance Fichiers de sorties sont regroupés sur une zone disque Grille de l'utilisateur (distante du CPU) sur la zone disque Grille associée au CPU; les données sont rapatriées plus tard par l'utilisateur Fichiers de sorties traités localement pour calculer le résultat de la mesure (valeur, histogrammes, maximum de vraisemblance,...)

12 Stéphane JEZEQUEL 23 Juin 2008 Intérêt d'un mésocentre au LAPP Pour la collaboration ATLAS (travail centralisé): Bénéficier d'une multitude de petites infrastructures (défi/contrainte EGEE: uniformiser les installations : ATLAS ~ 60 sites) Pour les informaticiens du LAPP Acquérir des compétences en calcul de masse Avoir une visibilité hors du laboratoire

13 Stéphane JEZEQUEL 23 Juin 2008 Intérêt d'un mésocentre au LAPP Pour les physiciens du LAPP Participer à l'effort commun de calcul en prolongement de l'effort commun de construction du détecteur Offrir des ressources informatiques pour leurs canaux de physique favoris Bénéficier de l'expertise Grille des admin. du site pour jobs qui plantent Béneficier de l'installation des données et du soft par ATLAS sur les sites Avoir accès avec du CPU local à la dernière version des données pour le développement d'algorithme de sélection d'evts et/ou extraction de mesure Possibilité de mettre à disposition d'autres collaborateurs ATLAS des données de développement Exemple récent: Congestion des ressources CPU habituelles au CERN, ->développement d'algorithme d'une méthode de calibration fait et validé plus rapidement sur le mésocentre du LAPP

14 Stéphane JEZEQUEL 23 Juin 2008 Conclusion Analyse des données d'ATLAS repose sur une Grille opérationnelle Depuis début périodes de validation de l'infrastructure Résultats globalement positifs Progrès nécessaires: Rendre l'accès aux données plus robuste (accès d'un disque par centaines de CPUs) De plus en plus d'utilisateurs à travers le monde Tournera en grandeur nature d'ici la fin de l'année