Quelle(s) application(s) pour GDS ? Eddy Caron LIP ENS Lyon Join work with A. Vernois and J.-Y. L’Excellent LIP, Lyon V. Garonne CPPM/IN2P3, Marseille

Intro Gestion des données dans 3 applications susceptibles d’utiliser les résultats de GDS  Bioinformatique: GriPPS  Solveurs creux: TLSE  Physique des particules: LHCb

Bioinformatique GriPPS The Grid Protein Pattern Scanning

Application bioinformatique: Contexte des banques de données de référence  fichiers texte « à plat »  de qq Mos � plusieurs Gos  mise � jour : de quotidienne à mensuelle  nombre et volume augmentent rapidement Requêtes  en très grand nombre  indépendantes  impliquant 1 ou 2 banques  temps d'exécution linéaire

Analyse des logs A partir des logs de :  des requêtes plus fréquentes que d'autres  blast sur sp.fas : 77% des requêtes  globalement, l'utilisation reste la même On peut utiliser l'analyse des requêtes précédentes comme point de départ.

Quelques chiffres Source: Traces du serveur de l’IBCP Number of databanks m23 Number of algorithms p8 Number of couple algorithm databanks80 Number of requests88730 Size of smallest databanks1 MB Size of largest databanks12 GB

Solveurs Creux : Grid TLSE

Grid TLSE: expert site for sparse linear solvers Tests for Large Systems of Equations Coordinated by ENSEEIHT-IRIT, Toulouse Funded by ACI GRID Goal  Provide a friendly test environment for expert and non-expert users of sparse direct linear algebra software  Easy access to software and tools, a wide range of computer architectures, matrix collections  On a user’s specific problem, compare execution time / accuracy / memory usage /  of various sparse solvers  public domain  as well as commercial,  sequential  as well as parallel  Find best parameter values / reordering heuristics on a given problem

Request Examples Memory required to factor a matrix Error analysis as a function of the threshold pivoting value Minimum time on a given computer to factor a given unsymmetric matrix Which ordering heuristic is the best for solving a given problem

Why using a grid ? Sparse linear algebra software makes use of sophisticated algorithms for (pre/post)-processing the matrix Multiple parameters interfere for the efficient execution of sparse linear solvers  Ordering  Amount of memory  Architecture of the target computer  Available libraries  Determining the best combination of parameter values is multi-parametric problem  Combinatorial nature of these parameters The installation of any sparse solver library on a new architecture can be a nightmare ! Testing different architectures Always using the latest version of each library

Is it realistic ? Time to send the data can be more important than the computation itself ! But  Large number of independent requests  Time to answer is not critical  Data persistency between elementary requests easy to express Clear need for the users !  Managing software and hardware testing from a PSE

Architecture ClientExpert Expert Site Grid TLSE Websolve Weaver DIET Database Matrix Collections History Log Files Scenarios Services StaticDynamic Connection Synthetic Results Expertise Request Solver Runs Partial Results Requests Results Consult/Modify Stats Client Provided Matrix Consult Modify Writes scenarios, deploy new software Sends experiment requests

Data management in GRID TLSE Access to large collections of sparse matrices (URLs of files outside the DIET architecture)  Matrix files can be large (sometimes a few GBytes in worst cases).  Each server manages a cache mechanism.  Use DIET plug-in schedulers (or load function) to help choosing the platform, example: if matrix file is not in cache (on disk) then server_adequacy= «bad» (the request will first download the file) else server_adequacy = «good» (the file is already available) endif  Requires at least the matrix name to be passed to the SeDs before choosing.

Data management in GRID TLSE Management of temporary data could be done using persistency/replication mechanisms within DIET Example: the user asks for the impact of reordering on his matrix for different solvers and platforms  Some services (MUMPS, UMFPACK, …) first compute permutations files.  Permutation files are then applied to different solvers on different platforms to perform the actual computation.  Results of elementary requests are presented to the user through the web interface.  Permutation files must be cleaned when the user’s (meta) request has completed.

Physique des particules

Expérience LHCb Installée auprès du futur collisionneur proton-proton le Large Hadron Collider a Genève (CERN) avec trois autres expériences  Démarrage prévue en 2007 Étude précise de la violation de CP dans les systèmes de mésons beaux produits lors de collisions proton-proton 40x106 collisions par secondes Taux de données: 200 Ko/200Hz Chaque collision ou évènement est indépendant :  La taille d’un évènement varie selon la physique observée: LHCb (physique rare), 3 Mo

Caractéristiques Gros volumes de données à:  Analyser  Générer par simulation de Monte-Carlo  Stockage de l’ordre de 1.3 péta octets par an  Partager 500 utilisateurs répartis sur 20 sites dans le monde

LHCb: Types d’applications Production de données:  Produire un montant donné en une période fixée Analyse de données:  Extraire la physique des données  Appliquer un algorithme sur un ensemble de données

DIRAC: Caractéristiques des applications Production de données Traitement des données Analyse de données Application Multiparamétriques Pas de dépendances de données Production de données CPU Bound Gros grain Dépendances de données Production de résultats I/O Bound Petit grain Planifié Pour une expérience Puissance de calcul/période «High Troughput Computing» (HTC) Chaotique/aléatoire Pour un utilisateur Temps de réponses/Job « High Performance Computing »(HPC)

LHCb: Data Challenge 2004 Produire et analyser des données en vue de préparer la mise en service du LHC (2007) Avoir 10 % des données du système final:  50 To de données/trois mois~ jobs  20 sites ~2000 Worker Nodes  Grande hétérogénéité des ressources Analyser ces données  Appliquant au préalable une sélection des fichiers intéressant par l’intermédiaire d’un service de méta-data

*approximatif car en cours de redéfinition, au moins un facteur 2… Ordre de grandeur* Par simulation:  700 To par an,  ~ fichiers  Taille des fichiers: ~1 Go  Sécable par événement de 3 Mo Par acquisition du détecteur:  Équivalent Analyse:  De 1 à 100 fichiers  Fichiers pouvant être lus partiellement  Traités par événement  Dépendances aux données peuvent être indéterminées au départ de la tâche

Outils usuelles de gestion des données Mass storage, storage classique Primitives de transferts: BBFTP, grid-ftp, etc. File catalog: correspondance logical file name, physical file name Meta-data catalog: permets de sélectionner les data sets intéressant Pas encore d’outils standards:  Replica Manager  (local/global) File transfer service  Pending file transfer service  …

Références gag/LCG_GAG_Docs/HEPCAL-prime.doc gag/LCG_GAG_Docs/HEPCAL-prime.doc

Question et Conclusion Conclusion : Il reste une question Question : Quelle(s) application(s) cible(s) pour GDS ?