Le Filtre d Événements d ATLAS François TOUCHARD CPPM en collaboration avec C. Bee, F. Etienne, E. Fede, C. Meessen, R. Nacasch, Z. Qian
Contenu de la présentation L expérience ATLAS Le système de déclenchement et d acquisition Le Filtre d Événements Flot de données Supervision Tests de validation
L expérience ATLAS ~ 2000 collaborateurs ~ 180 Instituts 44 m 22 m 7000 tonnes
Déclenchement et acquisition (1) taux de collisions initial : 40 MHz taille des événements : ~ 2 Moctets ~ 7 10 18 octets / jour! système de filtrage à 3 étages LVL1 : sur LAr Calorimètre et Muons LVL2 : en utilisant une fraction seulement des données (Concept de Région d Intérêt) Event Filter
Déclenchement et acquisition (2)
Spécificité du Filtre d Événement Dispose de la totalité de l information sur l événement Utilisera les algorithmes de reconstruction du offline Espère utiliser directement l environnement et le code Puissance de calcul requise ~ 250 SPECint95.s ~ 1000 processeurs
Échéances Soumission du Technical Design Report à la fin de 2002 préparation basée sur la réalisation de prototypes permettant de tester les différentes technologies qui pourraient être utilisées fermes de PC serveurs SMP Construction du dispositif final à partir de 2004
Développements effectu s au CPPM Étude d un prototype de ferme de PC flot des événements dans la ferme supervision (contrôle et monitorage) de la ferme Conception d une architecture indépendante du matériel et des protocoles de communication
Flot des événements basé sur une relation client serveur entre des composants, coordonnée par un serveur de noms design modulaire, orienté objet, des composants
Architecture générale
Éléments des composants
Flot des événements basé sur une relation client serveur entre des composants, coordonnée par un serveur de noms design modulaire, orienté objet, des composants Reconfiguration dynamique de l ensemble des composants machines d exécution protocoles de communication paramètres
Supervision Contrôle et monitorage de plusieurs milliers de processes tournant sur un millier (au moins) de processeurs rapide indépendant de la technologie nombreuses interfaces utilisateurs
Agents mobiles JAVA gérés par un serveur local sur chaque machine cible un agent migre de serveur en serveur et exécute localement une tâchet le code transporté par l agent peut provenir de nombreuses sources (web, file system, etc...)
Organisation générale moniteur de performances "local" supervision centrale à l aide d agents mobiles stockage intermédiaire des résultats pour une analyse différée
Supervision centrale un seul process peut contrôler la ferme lancement, arrêt des processes opérations de run control nombre illimité de processes de monitorage
Tests de validation Développements à Marseille sur une mini ferme Tests au CERN Cluster EFF (50 machines bi pro PII) Validation du dataflow et de la supervision Cluster MAGNI (24 machines bi et quadri pro) Intégration avec l ensemble du TDAQ
Tests de validation (2) Tests à ETH Zürich 240 machines bi processeurs (PIII 500 et 650 MHz, 1GB RAM, Ethernet 100 Mb/s et Gb/s) Performances (3000 processes créés en ~30 s) Rôle du serveur de noms
Futurs développements 2ème itération du design et de l implémentation Utilisation de l expérience acquise par les expériences en cours (Babar, CDF, D0,...) Détection et récupération des erreurs Mise en place du monitoring Du filtre De l expérience