Besoins en Calcul de CMS

1. Besoins en Calcul de CMS C. Charlot / LLR CTDR: https://cmsdoc.cern.ch/cms/cpt/tdr/cms-ctdr-bw.pdf

2. Les données du problème • Taille des RAW data estimée à 1.5MB pour le run de physique à 2x1033 • ~300kB d’après MC actuel • Facteurs multiplicatifs d’après Tevatron • Sous-estimation MC/vraies données: x1.6 • HLT commissioning: x1.25 • Démarrage, seuils, zéro suppression: x2.5 • Taille réelle plus proche de 1.5MB • Diminuera avec la connaissance du détecteur • Mais augmentera avec accroissement de la luminosité • Taux de déclenchement estimé à 150Hz pour le run de physique à 2x1033 • Taux minimal pour la physique et la calibration: ~100Hz • Physique « Standard Model »: + 50 Hz C. Charlot, Réunion CMS-France, mar. 2006

3. Principes de base • Code de reconstruction rapide • Re-processing fréquents • ORCA => ~25kSI2K.sec* pour jets pT=50-80 GeV/c, basse lumi • CMSSW devrait être plus efficace => à mesurer • Traitement des données suivant les priorités décidées par l’expérience • Calibration aussi bien que données « Higgs » • Streamed primary datasets • distribution et processing « priority driven » • Distribution jointe des RAW+RECO • Accès aisé à l’information « brute » • 1 copie au CERN + 1 copie complète distribuée • Formats de données compacts • Copies multiples à de multiples sites • Distribution T1 -> T2 * 1CPU 2006 = 2-3kSI2K C. Charlot, Réunion CMS-France, mar. 2006

4. Les lots de données primaires • Rôle prédominant de la sélection trigger dans l’analyse des données en physique pp • Part prédominante du filtrage dans l’analyse • Rappel: collisions 40MHz(collisions)150Hz(offline) 10-5Hz(100 évts Higgs dans un plot pour 1 an de stat.) • CMS prévoit de s’appuyer fortement sur la définition de lots de données primaires par le système de déclenchement • o(50) « primary datasets » (single électrons, diélectons, diphotons,..) • Y inclus calibration streams, « hot streams », « express-line » • Permet une affectation aisée de priorités pour l’analyse et le traitement des données • Distribution des données suivant les « primary datasets » • Conséquences importantes sur la physique supportée au site i C. Charlot, Réunion CMS-France, mar. 2006

5. Les tiers de données • Données brutes (« RAW »): 1.5MB/evt* • Produites par la DAQ du détecteur • 150Hz x 1.5MB x 107sec/an: 2.25PB/an • 1 copie au Tier0 et une répartie sur les Tier1s • Données reconstruites (« RECO »): 250kB/evt* • Produites par le programme de reconstruction • Objets reco de bas niveau • Hits reconstruits, clusters calorimétriques, traces, vertex reconstruits,.. • Liens vers l’information « RAW » • 1 copie au Tier0 et une répartie sur les Tier1s, distribuée avec les RAW => FEVT, au moins pendant les premières années • Données d’analyse (« AOD »): 50kB/evt* • Produites par le programme de reconstruction • Objets reco de haut niveau: Electrons, Muons, Taus, .. • Track refit possible, pattern recognition nécessite retour aux RECO • répliquées partout, ultimement utilisées dans la plupart des analyses * : pour 2 1033cm-2s-1 C. Charlot, Réunion CMS-France, mar. 2006

6. Data Flow C. Charlot, Réunion CMS-France, mar. 2006

7. Data Flow C. Charlot, Réunion CMS-France, mar. 2006

8. Opérations au Tier0 • Les streams du ONLINE arrivent dans un buffer de ~20 jours • Séparés en ~50 « primary datasets » comprimés en tailles de fichiers raisonables bâtis suivant les trigger paths • Le RAW «  primary dataset » est • Archivé sur bande • Place sur le buffer libérée • Envoyé aux machines batch pour la reconstruction au Tier0 • Les données RECO produites sont comprimées avec les données RAW correspondantes pour former le format distribuable FEVT • RECO archivée sur bande au Tier0 • FEVT distribuée aux Tier1s (souscription + push) • Chaque Tier1 reçoit 1/Ntier1 des FEVT soit ~5-10 « primary datasets » • Les « primary dataset » chauds peuvent être distribués à plus que 1 Tier1 • Une copie complète des AOD est envoyée à chaque Tier1 C. Charlot, Réunion CMS-France, mar. 2006

9. Les centres Tier1 • Définition finale et contributions sujettent au MoU LCG entre le CERN et les pays fournissant des moyens de calcul Tier1 et/ou Tier2 • États actuels des centres Tier1 ayant déclaré des ressources pour CMS: • ASGC (Taiwan) • CC-IN2P3 (France) • CNAF (Italie) • FNAL (USA) • FZK-GridKA (Allemagne) • NDGF (États nordiques) • PIC (Espagne) • RAL (UK) • Il est prévu également une fonctionalité Tier1 au CERN • CERN AF LCG MoU draft 31 jan. 2006 C. Charlot, Réunion CMS-France, mar. 2006

10. Opérations aux Tier1s • Reçoivent et prennent la responsabilité des données FEVT et AOD • Dataset courant sur disque • Le reste des données principalement sur bande avec cache disque frontal • Reçoivent les données simulées reconstruites des Tier2s • Les archivent • Distribuent les AOD de SIMU à tous les autres Tier1s • Effectuent le reprocessing officiel des données RAW/RECO et SIMU • Données RAW/RECO issues du T0 • Données SIMU importés depuis Tier2s • Servent les données courantes à tous les groupes d’analyses faisant des sélections • Produits d’analyse envoyés aux Tier2 pour analyse • Possibilités d’analyses locales C. Charlot, Réunion CMS-France, mar. 2006

11. Les centres Tier2s • Les ressources Tier2 font parties du MOU et comptabilisées comme ressources de CMS • Chaque Tier2 est associé à un Tier1 particulier, qui lui fournit des services de stockage et d’accès aux données dont il a besoin • Échanges AOD Tier1->Tier2 et MC Tier2->Tier1 • La totalité du MC est faite aux Tier2s • Rapport MC / data réelles: 1 / 1 • Reconstruit au Tier2, re-processing au Tier1 • Trois types d’utilisation des ressources Tier2 sont envisagés: • « CMS controlled use » : une fraction est dédiée à des activitées de processing générales de CMS, i.e. MC et processing d’analyse recquis par les groupes de physiques • « Local community use » : une fraction des ressource est complètement controlées par les « propriétaires » • « Opportunistic use » : chaque physicien de CMS peut utiliser ces ressources via la grille C. Charlot, Réunion CMS-France, mar. 2006

12. Les centres Tier3 • Structures de calcul servant les besoins des instituts • Peuvent fournir des ressources à CMS sur une base « opportunistic » • Ne font pas partie du MoU • Pas partie intégrante du processing centralisé de CMS • pas de support fournit par le computing de CMS • Néanmoins une partie importante des ressources pour l’analyse C. Charlot, Réunion CMS-France, mar. 2006

13. Estimation des besoins C. Charlot, Réunion CMS-France, mar. 2006

14. État actuel de la grille CMS • 2005: SC3 « service phase » utilisée comme test d’integration • ~0.29PB transférés via PhEDEx (tout SC3) • SC3 phase 2 (2 semaines): 140TB, ~autant que 2004! • Débit moyens ~20MB/s end-to-end • 2006: • SC4 • CSA06 C. Charlot, Réunion CMS-France, mar. 2006

15. Situation en France • Tier1 au CC-IN2P3 • Plan de déploiement des ressources (LCG-France) • CMS = 25% (ATLAS = 45%, ALICE = LHCb = 15%) • Tier2s en France pour CMS • GRIF • CC-IN2P3 AF • Strasbourg? • Tier2s hors France • IHEP (Beijing), contacts avecTier2 Belge LCG MoU 31 jan. 06 C. Charlot, Réunion CMS-France, mar. 2006

16. Conclusions • Calcul complexe dû à la volumétrie des données à traiter • Impossibilité matérielle de traiter/servir l’ensemble des données en un seul site • Également présence de ressources dans de nombreux pays/instituts de la collaboration • On s’attend à être submergé par les données • Aux Tier1s, aux Tier2s, aux Tier3s,.. • Nécessité de gérer des priorités, logique de filtrage • Mise en oeuvre au cours des DC, SC et autres CSAs • ~3 ans de pratique de transfert massifs de datasets, assemblage de collections, placement de données pour analyses remote par les end-users via la grille • Situation en France • CC-IN2P3: 2006 doit être une année d’augmentation significative des ressources via budget LCG • Projets de Tier2 ont démarrés C. Charlot, Réunion CMS-France, mar. 2006