Ressources Informatiques / ATLAS-LAPP Organisation et utilisation des ressources informatiques pour l'analyse Analyses de physique : ce qui consomme le plus en CPU/disque ATLAS : Méthodes d'analyse assez hétérogènes Formats de données hétérogènes Dépends des sujets / groupes de travail Il en va donc de même pour ATLAS-LAPP... Software : découplé de l'environnement ATLAS, ROOT + C ++ E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-1
Schéma d'analyse typique GRID Data samples Local storage Local analysis MC samples Data reduction (size, event pre-selection) GRID disks Local disks Batch nteractif Results ROOT Ntuple format ~ 1 time per month Up to 0.7 % size reduction factor (Data) ~ 2/3 times per day E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-2
Au LAPP Différents sujets d'analyses Méthodes et ressources utilisées par sujet différentes Recherche de Z' (+ recherche de technicolor, L. Helary) Etude du W Etude du Z Photons et H E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-3
Recherche de Z' Au CC-Lyon : MC non-réduits disponible sur disques grille (gérés par ATLAS) Analyse en batch : ~ 150 jobs de ~1h ~ 1 nuit pour tourner sur l'ensemble Au LAPP : Données et MC réduits sur disque grille local (3-4 T) Analyse en batch : 100 200 jobs ~ 1.5 à 2h pour tourner sur l'ensemble Besoin de calcul pur : ~ 700 jobs de 1h30 chaque Excellente efficacité du batch LAPP vs. CC Accès des disques grilles bien plus compliqué au LAPP vs. CC E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-4
Boson W Première réduction des données / MC sur la grille ~ 2 jours pour l'ensemble des données Idem pour les MC Partie critique : rapatriement en local des lots réduits (très long) Toute l'analyse est faite a Sheffield MC réduits copiés sur disque local (1.5 T) Analyse en batch : ~ 160 jobs de 2h, 30 en parallèle ~ 1 journée pour tourner sur l'ensemble Historiquement analyse pas faite au LAPP par manque de disque accessible par le batch E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-5
Boson Z Première réduction des données / MC sur la grille ~ 1 à 2 semaines pour l'ensemble des données + MC, rapatriement inclus Stockés au CC (sps) et LAPP (lapp_data) Analyse au LAPP Données + MC réduits copiés sur lapp_data (1.8 T) Analyse en batch : ~ 700 jobs de 2 à 3h, ~ 150 en parallèle max. 3h (x 2) pour tourner sur l'ensemble E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-6
Photons Première réduction des données sur la grille Tache non faite au LAPP Stockés au CC (sps), ~ 5.5 T Analyse au CC PROOF ou machines interactives 15 min à 2h Utilisent aussi une analyse électrons faite sur la grille E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-7
Résumé La partie d'analyse est principalement faite avec du CPU local En pratique seul la réduction des données / MC est faite sur la grille La somme des ressources hors grille nécessaire aux analyses est importante Tout ne peux pas être fait au LAPP Part importante faite au CC Intérêt pour une analyse de travailler sur plus de 1 site Faire face aux «downtime» (surtout CC!) E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-8
En cas... E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-9
Distributed analysis E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-10
A typical production Samples size: Data sets of 150 to 7000 files Sizes of 300 G to 4.5 T Number of jobs: Grid sub-jobs: [50 to 900] x ~ 80 Not all 80 grid jobs launched at the same time, otherwise too complicated to monitor ~ each 1-1.5 month, due to ATLAS constant developments, changes, bug fixes, general un-stability A complete production takes 1-2 weeks (depends on grid reliability) E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-11
Submission and monitoring Prun launching a tarball of private root-based code Personal scripts to automatised the submission A sequence of prun commands for different grid data sets Minimal book-keeping of launched jobs (to ease re-submission) Monitoring: Mainly panda monitor pbook to (try to) relaunch failed sub-jobs E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-12
Encountered Problems In general: grid reliability Fraction of failed jobs is generally small, but extremely annoying when >100 sub-jobs In particular Not easy to re-launch failed sub-jobs rapidly to another site A panda monitor feature : in case of automatically relaunched sub-jobs, no easy way to check if finally all initial sub-jobs succeeded We need to check relaunched sub-jobs 1 by 1?? Large samples: many sites, increased risk of failure and processing tine Slow to retrieve outputs (50 to 200 G dispatched on many sites) [with the drawback I am (still) using dq2-get] E. Sauvan LAPP Annecy Réunion Service Informatique, LAPP - 24/04/12-13