ATLAS et l’analyse au CCIN2P3  Le modèle de calcul de ATLAS  L’analyse à Lyon  Points critiques Avertissement : cette présentation n’est malheureusement.

Présentation au sujet: "ATLAS et l’analyse au CCIN2P3  Le modèle de calcul de ATLAS  L’analyse à Lyon  Points critiques Avertissement : cette présentation n’est malheureusement."— Transcription de la présentation:

1 ATLAS et l’analyse au CCIN2P3  Le modèle de calcul de ATLAS  L’analyse à Lyon  Points critiques Avertissement : cette présentation n’est malheureusement pas donnée par la bonne personne Un grand merci à Éric pour les transparents sur le modèle de calcul !

2  Le modèle de calcul  Les données :  RAW : données brutes, format ‘bytestream’, 1.6 MB/evt (stat. attendue en 2009/2010 : ~ 1G evts)  ESD : ‘Event Summary Data’, format POOL/ROOT, 0.5-1 MB/evt résultat très détaillé de la reconstruction (e.g. information suffisante pour re-ajustement de traces, recherche et étalonnage des jets…)  AOD : ‘Analysis Object Data’, format POOL/ROOT, 100 kB/evt résumé de la reconstruction, suffisant pour la plupart des analyses  DP n D : ‘Derived Physics Data’ ~ petit AOD pour n = 1,2 peut être un ntuple ou des histogrammes standard pour n ≥ 3  TAG : ‘Tag Data’ 1kB/evt utilisés pour une sélection rapide des événements (~ base de données) En 2009/2010 : utilisation intensive des ESD (et RAW) pour étalonnage, compréhension du détecteur, etc… En mode stable (> 2010) l’analyse utilisera essentiellement les DP n D

3  L’organisation du calcul BNL LPC Tokyo NW GRIF T3 NET2 FR Cloud BNL Cloud Pékin NG LYON BNL FZK TRIUMF ASGC PIC SARA RAL CNAF CERN Clermont LAPP CCPM Roumanie SWMW GL SLAC TWT2 Melbourne  10 nuages formés de 1 Tier1 et n Tier2/Tier3 sur le Tier1 : - stockage 10% RAW, 20% ESD, 100% AOD - reprocessing (et redistribution) sur les Tier2 : - stockage 100% AOD sur ∑(Tier2) - production Monte-Carlo - analyse  Un Tier0 : CERN - stockage des RAW - première reco. - distributions des RAW/ESD/AOD Les Tier0,1 et 2 sont vus par tout ATLAS Les Tier3 ne sont pas intégrés à l’organisation Grid

4 Made in central production (T1) Made in T2/T3  Le modèle d’analyse ARA : AthenaROOTAccess permet de lire les objets (quantités reconstruites) directement dans ROOT Athéna : cadre logiciel de base (avec Gaudi, en collaboration avec LHCb)

5 Le rôle du CC : Lyon est le Tier1 français  Stockage : - 10% RAW sur bande, 1% sur disque - 20% ESD (disque) - 100% AOD, DP 1 D - constantes d'étalonnage (base de données ORACLE)  Reconstruction : - reprocessing : RAW  ESD  AOD - production des DP 1 D (contenu défini par les groupes de physique)  Accès aux RAW/ESD pour étalonnage, corrections du code, développements des algorithmes  Une spécificité absente du modèle de calcul : Comme dans d’autres Tier1, il a été décidé de profiter de l'accès local aux données pour installer une ferme d’analyse dimensionnée pour ~ 80 utilisateurs

6  L’analyse à Lyon  Méthode traditionnelle, la voie facile  Souvent plus facile d’utiliser le batch non grid données (éventuellement privées) archivées sur hpss, sps ou dCache + batch pour - reconstruction privée, possible pour de faible volume de données - produire des ntuples analysés en interactif - analyse directe, e.g. via ARA  Si données facilement accessibles (e.g. privées) méthode très efficace, retour rapide  La voie facile n’est malheureusement pas la bonne méthode (recommandée) et n’est pas viable dès que de gros lots de données sont considérés

7  Méthode ‘officielle’ : la voie difficile via la Grille  Actuellement, le CC est plus utilisé comme élément de calcul et de stockage que pour l’analyse interactive - Préparation : où sont les données (datasets) ? Outils de gestion des données (DDM), e.g. DQ2 Cas idéal et mode stable : analyse des AOD et DP 1 D : toutes à Lyon - Lancer les jobs avec les outils PanDA ou Ganga - Récupérer les résultats Avec PanDA, ces résultats sont des datasets enregistrés automatiquement sur la Grille et DQ2 permet de les récupérer facilement Selon l’utilisateur, les datasets de sortie peuvent correspondre quasiment aux résultats finals, e.g. histogrammes pour figures finales, ou au contraire correspondent juste en une copie dans un format agréable (e.g. ntuple plat) d’une part des info. contenues dans les AOD ou DPD, pour analyse plus lourde dans ROOT (par exemple, refaire l'étiquetage des jets beaux)

8  La partie interactive dépend beaucoup de l’utilisateur, pas de procédure recommandée pour le moment  stockage temporaire sur disque semi permanent sps et analyse interactive  stockage temporaire sur disque semi permanent sps ou sur hpss et analyse batch  récupération des ntuples sur PC personnel pour analyse locale Ces procédures artisanales ne sont possibles uniquement que pour des volumes de données relativement faibles  doit évoluer rapidement pour le début de la prise de données. Par exemple :  mettre en oeuvre xrootd + PROOF à Lyon  pour les Tier2/3 : glitePROOF (tests au CPPM)

9  Les points critiques  Le hardware le plus important : Préparation de l’analyse, compilation : AFS Le code ATLAS est TRÈS lourd, beaucoup de dépendances à contrôler  si AFS est lent ou instable, extrêmement difficile de travailler  plusieurs utilisateurs ont essayé de développer du code au CC… … et sont vite repartis ailleurs  une part de responsabilité vient de ATLAS, pour une gestion approximative du stockage des releases (résolu ?) L'accès aux données et dCache  Les événements et les conditions (constantes d'étalonnage, etc…) sont stockées sur dCache  Malheureusement dCache n’est pas stable ni fiable !

10 Les problèmes avec dCache :  Des fichiers existant dans le catalogue ne sont en fait pas présents dans dCache  Au mieux, les jobs échouent (extrêmement désagréable pour un job Grille, par exemple, qui doit lire 50 fichiers, mais échoue car l’un d’entre eux n’est pas trouvé)  Au pire, les jobs ne font rien, aucun diagnostique possible par l’utilisateur (l'équipe du CC peut déterminer les fichiers problématiques qu’un job essaie d'accéder)  Manque de fiabilité : des fichiers sur dCache peuvent disparaître ! (ou c’est l’impression qu’on a) … plutôt effrayant … (heureusement que les RAW existent en 2 exemplaires à travers le monde)  Lenteur : l'accès aux données dans les jobs Athéna semble très lent Tous ces points faibles conduisent à la situation absurde dans laquelle beaucoup d’utilisateurs copient (parfois en les cherchant sur d’autres sites) les données sur sps avant de les utiliser. Cela ne sera évidemment plus possible au démarrage de la prise de données.  Sur cet aspect, nous ne sommes absolument pas prêts (je pense…)

11  Le CC par rapport au CERN ou BNL  Préparation de l’analyse, partie interactive : besoin de compiler souvent donc rapidement : en général, très pénible au CC Au CERN, AFS semble beaucoup plus rapide.  la majorité (tous ?) des développeurs travaillant en France sur les nightlies (version du code mise à jour quotidiennement) le font au CERN  En revanche, l’utilisation du batch au CERN est pénible (temps d’attente beaucoup trop long, vu le nombre d’utilisateurs)  préparation du code au CERN, soumission des jobs ailleurs (au CC)  De plus en plus d’utilisateurs soumettent les jobs Grille via PanDA Par défaut, ils tournent à BNL Démarrage rapide des jobs (malgré un grand nombre d’utilisateurs) et retour rapide Si on force à tourner à Lyon : longue attente avant démarrage (parfois justifiée par un grand nombre de jobs en queue, parfois incompréhensible) + problèmes dCache  beaucoup d’utilisateurs choisissent le site par défaut, i.e. BNL (sauf cas de force majeur, e.g. utilisation de datasets absents à BNL)

12 Un exemple concret (C. Collard) : Le même job, sur le même dataset, à Lyon ou BNL :  Réponse en moins d’un jour à BNL, taux d'échec faible  Au CC, temps de réponse jusqu’à 1 semaine ! Et taux d'échec élevé  Pour être tout à fait juste : En février et mars : les stats. de BNL ont un peu chuté Sur la même période, le CC semble en net progrès (aux problèmes de dCache près) Cependant, en intégré, depuis que l’utilisation de Grille/PanDA s’est généralisée pour l’analyse BNL semble loin devant Lyon, c’est notre référence

13  Le CC n’est pas du tout prêt pour l’analyse efficace des données d’ATLAS (mon opinion)  AFS et dCache sont des facteurs extrêmement limitants  Même s’il semble y avoir des progrès depuis ~ 1 mois, beaucoup de choses restent à améliorer rapidement, notamment un support plus réactif une meilleure distribution des informations (par exemple des news plus explicites) more work is needed…