BABAR Georges Vasseur CEA Saclay, DSM/IRFU/SPP Workshop sur l’analyse des données au centre de calcul de Lyon 17 avril 2008

L’expérience BABAR Collaboration internationale basée au SLAC en Californie. –Environ 600 physiciens. –5 labos français. Etudie la violation de CP et la physique des saveurs lourdes. –Besoin d’une grande statistique. Prise des données : – de mai 1999 à avril 2008.

Organisation du calcul Calcul distribué sur plusieurs centres : –SLAC –Lyon –(RAL) –INFN (Rome / Padoue) –GridKa Répartition des données filtrées (skims) entre les différents centres. Conséquence : utilisation du CC par des membres non français de BABAR.

Modèle de calcul Dénoté CM2 (« Computing Model 2 ») –Post objectivity. –Modèle de calcul officiel de BABAR à partir de l’été Basé sur le format ROOT –Stockage des données. –Conditions et configuration. Analyses basées sur le format « MICRO ». –Il existe aussi un format « MINI ».

Quelques chiffres Lot final : –465 millions d’événements BB. –Plus de 2 milliards d’événements hadroniques. Taille d’un événement: 3 kB (MC: 6kB).

Données A Lyon, collections « AllEvents » et un grand nombre de skims. –Données réelles, Monte Carlo générique et spécifique. Transfert depuis SLAC via SRB. Stocké dans HPSS. Staging dynamique dans l’espace xrootd.

Code d’analyse Code distribué (CVS). Organisé en releases. –Code de reconstruction, simulation. –Mais aussi code d’analyse. Releases d’analyse. Plusieurs processings des données. Systèmes d’exploitation : –SL3 jusqu’à récemment. Code tourne sous SL3 et SL4 – 32 bits. –SL4 pour les dernières releases.

Organisation de l’analyse Groupe de travail par sujet d’analyse –Centre de calcul attribué 6 groupes de travail à Lyon –Disques de groupe GPFS /sps/babar à Lyon Etapes de l’analyse –Production à partir des skims → gros ntuples –Réduction → petits ntuples –Analyse finale : ajustement, validation

Production des données Tourner sur les skims pour écrire des gros ntuples. Très bonnes performances –Un facteur 5 à 10 de mieux par rapport au SLAC. –Espace disque suffisant. Utilisation de l’espace scratch du worker. HPSS/xrootd, GPFS. Point noir : –Collections manquantes (des jobs échouent → perte de temps).

Réduction Appliquer une sélection plus stricte. Garder les variables pertinentes. Ecriture de petits ntuples, utilisés ensuite à de multiples reprises. Stockage sur : –GROUP_DIR, GPFS, –HPSS/xrootd. Utilisation interactive.

Analyse finale Ajustement final souvent complexe. –Plusieurs observables. –Plusieurs quantités à mesurer. –Beaucoup de paramètres libres. Procédure de validation: –Génération d’expériences simulées. Demande du CPU –Lancé en batch.

Support Pages web pour l’utilisation du centre de calcul pour BABAR. Forum de discussion : –Nouvelles, problèmes et solution. Point positif : –Rapidité et efficacité du support en cas de problème (Jean-Yves) Point négatif : –En cas de problème temporaire, difficulté d’avoir des nouvelles (délai, …)

Conclusion Beaucoup d’analyses de BABAR se font au centre de calcul de Lyon. –Très bonnes performances. –Largement supérieure à SLAC. BABAR a pu tiré parti du CPU, des disques et du système HPSS à Lyon. Le support fourni par le CC est apprécié.