Simulation, modélisation, traitement des données

D. Buskulic, Maubuisson 2001 1

Simulation, modélisation, traitement des données

Une approche pragmatique


I. Généralités

I.1 Contraintes sur les outils de Physique Corpusculaire


Quantité de données à traiter

1 Teraoctet à quelques Petaoctets/an ! 1015 octets 1000 Teraoctets 20 000 bandes d'aujourd'hui 100 000 DVD RAM double face 1 500 000 exemplaires de l'Encyclopaedia

Universalis !

Seulement 1 evt sur 106 est intéressant ! 1 sur 109 REELLEMENT intéressant !

-> Data Mining (recherche d'une aiguille dans une botte de foin)


Ca va plus vite que la loi de Moore

Données Babar


Conséquences

Importance des outils de gestion des données (bases de données)

Importance des outils d'analyse statistique L'analyse requiert un accès efficace aux

données et aux fonctions


Quantité de calculs nécessaires

Grande puissance de calcul nécessaire pour simuler/reconstruire/analyser les données

1000 à 10000 PC d'aujourd'hui (fermes) Importance du calcul parallèle Futur : calcul distribué


I. Généralités

I.2 Critères et fonctionnalités à respecter


Comment faisait-on une analyse ?

Détecteur

Traitementbatch

histos…

Modèle "Batch"

Données


Un meilleur modèle

Détecteur ou simulationRaw Datacoups ADC…

DSTtraces, etc…

Ntuplevaleurs calculées

histos…

Reconstruction

Analyse

une fois

un grand nombrede fois

Mais ca ne suffit pas pour traiter les données LHC !


Tâches à effectuer : exemple

Calibrer les signaux Extraire les composants

élémentaires (traces) Reconnaître les particules

individuelles Reconnaître les

caractéristiques physiques de l'événement

Extraire les quantités physiques

Recette :

Et ceci 10 millions de fois !


Tout ceci dans une grande variété de situations : Près du détecteur : algorithmes de reconstruction, études sur

l'évolution des performances…

Etude d'une grande quantité d'événements Etude d'un seul événement marquant Analyse de signal Comparer théorie et résultats expérimentaux

Title: dtall.epsCreator: HIGZ Version 1.26/04Preview: This EPS picture was not saved with a preview (TIFF or PICT) included in itComment: This EPS picture will print to a postscript printer but not to other types of printers

Reste à étudier la physique, mesurer, publier…


Problèmes cruciaux

Où se trouvent les données ? Plusieurs Petaoctets doivent être distribués

Plusieurs centres de stockage interconnectés

Où sont-elles traitées ? Traitement également distribué, au plus près des

données

Un problème d'une telle dimension ne peut être résolu qu'internationalement Exemple : Babar a deux sites de stockage/calcul,

Stanford et Lyon (CCIN2P3)


Influence sur les modèles d'environnement de travail

Concilier : Point de vue de l'utilisateur

Besoin de "toucher et voir", manipuler les données pour acquérir une compréhension des problèmes

La boucle expérimentale est dans l'analyse Doit pouvoir traiter aussi bien de petites quantités de

données "à fond" que de grosses quantités

Point de vue du concepteur du système Fermes de production centralisées Calcul local/distribué Modèles informatiques ? (Software Engineering)

Frameworks vs Composants, méthodes de conception


Influence sur les modèles d'environnement de travail

Modèles d'environnements de travail :

Composants Boite à outils Services


Comparaison des approches

Physiciens habitués à la boîte à outils Outils puissants Contrôle tout depuis le début Mais pas adapté aux flux de données actuels

Approche "composants" (Plug-ins) permet de se concentrer plus sur le problème

peut oublier certains "détails" -> lesquels ? Peut-on faire tout ce que l'on veut ?

Approche "services" comme compromis En s'assurant que l'on peut tout contrôler

Exemple des approches actuelles : dans la suite du cours


II. Programmation et langagesOrientés Objet

II.1 Motivations


Evolution

La quantité et la complexité des données rendent nécessaire une certaine forme d'abstraction des détails de base

Exemple : fabrication des ordinateurs

1950 : tubes 1960 : transistors 1970 : circuits intégrés 1980 : microprocesseur 1990 : microcontrôleurs 2000 : ordinateur sur une puce

Quel concepteur de PC s'occupe de savoir ce que fait chacun de 20 Millions de transistors dans un microprocesseur ?

Com

plexité des tâches

Com

plexité des briquesélém

entaires


On peut essayer d'adapter les vieux outils

Mais il faut parfois faire des sauts conceptuels


Couplage

Des parties de code d'analyse (reconstruction) vont remonter le diagramme

Réutilisation du code, simplicité

Peut-on transférer un objet complexe dans un nœud de trigger ?

Ex : une trace qui sait comment calculer sa quantité de mouvement

Ex : un histo qui sait comment se tracer lui-même

Ntuples

Raw

DST

Histos


Un bon logiciel c'est…

Vous écrivez vos logiciels pour les autres ! Un bon logiciel doit :

Avoir une structure aisément compréhensible Pouvoir être facilement débogué Autoriser facilement le changement d'une partie

sans affecter les autres parties Avoir un code modulaire et réutilisable Etre simple à maintenir et mettre à jour Etc…

La programmation orientée objet (POO) vous aide à écrire de bons logiciels… mais…


Ce n'est pas la panacée ! L'utilisation d'un langage dit "orienté objet" ne

garantit pas une "programmation orientée objet" Un code mal écrit en C++ est pire qu'un code mal

écrit en Fortran Les langages OO ne sont destinés qu'a

simplifier une bonne programmation OO Le langage est un outil pour arriver à l'orientation

objet


Programmation orientée objet : histoire

Plus de 30 ans de développements, d'expérience et de pratique de programmation

1967 : Simula67 1980 : Smalltalk80 Lisp, Clu, Actor, Eiffel, Objective C C++ et Java

Motivation La crise du logiciel (1980-1990):

Matériel de plus en plus puissant et peu cher Logiciel de plus en plus complexe et cher

Besoin de rendre le code réutilisable Cache les détails de l'implémentation d'un algorithme,

programme ou structure au monde extérieur, montre juste une interface.



II.2 Principe et concepts de base


Principe de base

L'idée est de représenter le comportement du monde réel sous une forme qui cache les détails de l'implémentation

Lorsque ca fonctionne, la POO permet de penser en termes de domaine élargi du problème


Trois idées de base

Trois idées fondamentales caractérisent la Programmation Orientée Objet : Classe/Objet

Encapsulation Hiérarchies de classes Héritage Abstraction / Polymorphisme



II.3 Classes, Objets et Encapsulation


Classes et Objets

La POO est une manière de programmer centrée sur les objets (Quoi ?) plutôt que sur les procédures (Comment ?)

Les objets et leur comportement sont très fortement liés

Données et comportements sont regroupés dans des classes dont les instances sont des objets

Une classe représente un type de "chose" dans le système, un objet représente une chose particulière.

Ex. : classe "trace" est un type, la trace particulière "+no 23" est un objet


Classes et Objets

Finalement, la POO voit la programmation comme une activité de simulation de comportement.

Ce qui est simulé, ce sont des objets représentés par une abstraction dans le programme


Classes et objets

Les classes sont responsables de leur comportement

class Impulsion{public : Impulsion(double x0, double y0, double z0, double e); ~Impulsion(); Impulsion& operator= (const Impulsion & droite); Impulsion& operator+ (const Impulsion & droite); double Module();…


Classes et objets

En C++, on peut définir les opérateurs standard (=, +, -, *, / ) pour une classe

Une classe est un type comme un autre (float, double,…)

Améliore la lisibilité du code

Impulsion a,b,c;c=a+b;


Classes et objets

Les données membres d'une classe ont une relation d'appartenance (possède un)


Encapsulation

Une classe possède une implémentation des détails de son comportement et une interface vers l'extérieur

Les détails d'implémentation doivent être inaccessibles de l'extérieur, c'est à dire des codes et objets qui utilisent la classe.

Les données membres de la classe doivent être privées, accessibles seulement à travers des fonctions membres (méthodes) du type Set/Get


Les changements de l'implémentation interne ne doivent pas modifier la façon dont on accède et utilise la classe extérieurement

Encapsulation

class Impulsion{…private: double m_Px; double m_Py; double m_Pz; double m_E;public: double GetP() const; void SetP(double p);

class Impulsion{…private: double m_P; double m_Theta; double m_Phi; double m_E;public: double GetP() const; void SetP(double p);

Données internes(privéees)

Méthodespubliques



II.4 Hiérarchies de classes et héritage


Héritage et hiérarchies de classes

L'héritage est un moyen de dériver une nouvelle classe de classes préexistantes, appelées classes de base

La nouvelle classe dérivée peut utiliser le code de sa ou ses classes de base

A travers l'héritage, on peut créer une hiérarchie de classes qui partagent du code et des interfaces

L'héritage est une méthode pour gérer la complexité


Hiérarchie de classes

L'héritage correspond à une notiond'identité ("est un")


TObject

Event

Segment

Track

Vertex

Momentum

MassSquared

InterceptAtVertex

est un possèdeun

•po

ss èd

eu

n

•possèdeun

•possèdeun

•po

ss èd

eu

n

•possèdeun



II.5 Abstraction et polymorphisme


Abstraction

On peut définir des classes destinées uniquement à donner naissance à d'autres classes par héritage

Ce sont des classes "abstraites" Permet

De définir une interface générale ("abstraite") De simplifier la modularité et la portabilité du code

Par exemple GEANT4 est libre de tout choix de techniques d'entrées/sorties ou d'histogrammation. De même, le GUI (Graphical User Interface) et la visualisation sont complètement isolées du noyau de GEANT4 par l'intermédiaire d'interfaces abstraites


Polymorphisme

Le polymorphisme prend de nombreuses formes : Surcharge de fonctions et d'opérateurs Redéfinition de fonctions membres d'une classe

de base par une classe dérivée Patrons (templates) de classes


Polymorphisme : surcharge

En POO, une fonction peut avoir le même nom, mais des arguments différents. Exemple

Draw(TLine* ligne)Draw(TBox* carre)

On ne trace pas de la même manière une ligne et un carré

La distinction est faite par le compilateur sur le type des arguments ("signature" de la fonction)


Polymorphisme : surcharge

On peut également en C++ surcharger des opérateurs

Ex: La somme de deux histogrammes peut avoir un sens. On peut surcharger les opérateurs "+" et "=" pour permettre h3 = h1 + h2;

Ne le faites que si vous savez où vous mettez les pieds !


Polymorphisme : redéfinition

Lorsqu'une classe dérivée a besoin de réaliser une opération définie dans la classe de base mais un peu différemment, elle peut redéfinir la fonction membre de la classe de base

Ex. : fonction "Draw". Si la classe "TArrow" dérive de la classe "TLine", il faudra ajouter le code de tracé de la pointe de la flèche. Ceci peut se faire dans la classe dérivée en redéfinissant la fonction membre "Draw".


Polymorphisme : redéfinition et … pièges ! class Base{

public: Base() {;} virtual void Affiche(int i) {cout<<"Int"<<endl;} virtual void Affiche(double i) {cout<<"Double"<<endl;}}

class Derive : public Base{

public: Derive() {;} virtual void Affiche(int i) {cout<<"Int"<<endl;}}

main(){ Base* a = new Derive(); a->Affiche(1.0);}

-> affiche "Int" !


Polymorphisme : Patrons de classes

C++ a la notion de polymorphisme paramétrique. Kézaco ?

Un patron de classe (template) permet de définir une classe indépendamment d'un type

Ex : un tableau de nombres, qu'ils soient entiers, longs, float ou doubles

Principalement utilisé dans la librairie STL (Standard Template Library). Facilite le développement.

Conseil personnel : n'allez pas au delà de l'utilisation de STL…



II.6 C++ et Java


C++

Origine : les labos AT&T (Bjarne Stroustrup) Le C++ a été conçu comme une extension du C qui

prend certaines libertés avec les concepts POO "purs" L'encapsulation n'est pas obligatoire On mélange les fonctions (procédures) du C et les classes et

leurs fonctions membres Conséquence : on peut très bien écrire un programme

procédural en C++ Principal mérite : a permis une transition "acceptable"

de la programmation procédurale vers la POO Principal défaut : trop de liberté d'action. Il est facile de

mettre le fouillis dans du code Quelqu'un a déjà eu des démêlés avec des pointeurs ?


Java

Origine : Sun Microsystems (1991) Objectifs :

Simple : syntaxe "C" Sûr : pas de manipulation de pointeurs, vérification du code

à l'exécution Orienté Objet : Ni variables, ni fonctions globales Robuste : Ramasse-miettes, fortement typé, gestion des

exceptions Indépendant de l'architecture sous sa forme "interprétée"

-> mais lent dans ce cas

C'est de la POO "pure"


Java : langage orienté objet

Langage orienté objet : TOUT est classe (pas de fonctions) sauf les types

primitifs (int, float,…) et les tableaux Toutes les classes héritent d'une classe de base

java.lang.Object Héritage simple


Java : avantages

Portabilité Le compilateur java génère du "byte-code" Les "Java Virtual Machine" présentes sur de

nombreuses plateformes : Unix, Win32, Mac, Netscape, IE,…

La taille des types primitifs est indépendante de la plateforme

Java est toujours accompagné d'une librairie standard

Robustesse Compilateur contraignant


Java : différences avec le C++

Pas de structures, d'unions Pas de types énumérés Pas de typedef Pas de préprocesseur Pas de variables, de fonctions en dehors des classes Pas d'héritage multiple Pas de surcharge d'opérateurs Pas de passage par copie pour les objets Pas de pointeurs, manipulation de référence seulement


Java : l'avenir ?

Peu de compilateurs natifs sont disponibles handicap, ne peut pas pour l'instant faire de calcul

scientifique sérieux Mais ca change (compilateurs JIT = Just In Time)

Avantages de robustesse et l'approche "OO pur" Très séduisant

Les utilisateurs, en physique corpusculaire, commencent juste à intégrer les concepts OO et à basculer en partie vers le C++

-> peut-on leur demander encore un effort ? Et Quand ? Heureusement, la syntaxe est proche du C/C++


III. Panorama des outils de simulation et d'analyse

disponibles et à venir…


Outils de simulation

Passé, présent : Simulation de détecteurs : GEANT 3 Generateurs d'événements : Pythia, Venus,

FLUKA,…. Futur :

Simulation de détecteurs : GEANT 4 Générateurs d'événements : interfacés aux

environnements de travail et/ou réécrits en C++


Environnements d'analyse

Passé, présent PAW Environnements "maison"

Futur ROOT JAS (Java Analysis Studio) Anaphe (ex LHC++) Open Scientist

On a le choix… quoique…


JAS (Java Analysis Studio)

Basé entièrement sur Java En hérite les avantages et inconvénients

Inclut en gros les fonctionnalités dont nous avons besoin en Physique corpusculaire

Très modulaire Indépendant du format de données Reste du travail à faire, mais concept

intéressant

http://jas.freehep.org/


Anaphe

Ex LHC++ Principalement basé sur des produits

commerciaux

http://anaphe.web.cern.ch/anaphe/


Open Scientist

Extrêmement modulaire (pb de cohérence ?) Essaye de récupérer et intégrer des codes

libres existants

http://www.lal.in2p3.fr/OpenScientist/


ROOT

On va en reparler de façon extensive…


IV. Exemple d'un outil de simulation : GEANT 4

IV.1 Introduction


GEANT4 : Introduction

GEANT est un outil de simulation pour les détecteurs. Il fournit une infrastructure générale pour :

La description des géométries et matériaux Le transport de particules et leur interaction avec la matière La description de la réponse du détecteur La visualisation des géométries, traces et coups

L'utilisateur développe le code pour Le générateur d'événements primaire La description de la géométrie du détecteur La numérisation de la réponse du détecteur


Historique GEANT3 Utilisé par la plupart des expériences de physique

corpusculaire Développement terminé depuis Mars 1994

(Geant3.21) Utilisé également en médecine, dans le spatial,… Résultat : système complexe

Domaine complexe Nécessité d'un outil flexible Maintenance inextricable


Limitations de la maintenance GEANT3 : Il devenait impossible d'ajouter une fonctionnalité

ou de rechercher un bug, à cause de la structure trop complexe dominée par des contraintes historiques

Limitation de FORTRAN Problème de main-d'œuvre au CERN Limitations d'un support centralisé


GEANT4 Collaboration internationale Adoption de méthodes d'ingénierie logicielle (OOA

et OOD) Choix de l'orientation objet et C++


GEANT4 : historique et futur Début du projet : Déc. 94 Geant4 0.1 : Juillet 99 Geant4 2.0 : Juin 2000 Geant4 3.2 : Juin 2001 Encore 10 ans de maintenance et améliorations


GEANT4 : Performance "Geant4 is faster than Geant3 in all aspects when its power

and features are well exploited" GEANT4 : Flexibilité

Implémentations et modèles alternatifs Ouvert à une évolution future :

Interfaces pour logiciels externes Extensible, implémentation de nouveaux modèles et

algorithmes sans interférer avec logiciel existant Tout est ouvert à l'utilisateur :

Choix des processus physiques et des modèles Choix de l'interface graphique / technologie de visualisation



IV.2 Présentation


Simulation de détecteur dans un cadre OO

En physique corpusculaire, la simulation revient à faire de la réalité virtuelle

Pour aider à la conception des détecteurs durant la R&D Pour comprendre la réponse du détecteur pour les études

de physique Nécessité de modéliser les interactions particules-

matière, la géométrie et les matériaux pour propager les particules élémentaires à l'intérieur du détecteur

Il faut également décrire la sensibilité du détecteur pour générer les données brutes (RAW data)


Simulation de détecteur dans un cadre OO

GEANT4 est une boite à outils orientée objet fournissant les fonctionnalités nécessaires pour les simulations de détecteurs

Les bénéfices inhérents aux concepts OO permettent un logiciel Facile à maintenir et développer Modulaire Aisé à comprendre pour les non initiés



IV.3 Concepts de base


Concepts de base

Run, Event, Track, Step, Trajectory Processus physiques Partie sensible d'un détecteur et coups Classes Manager


Run

Un "run" dans Geant4, comme dans une expérience réelle, commence par "BeamOn"

Un run est un ensemble d'événements partageant les mêmes conditions de détection Dans un Run, l'utilisateur ne peut pas changer

La géométrie du détecteur Les réglages des processus de physique Le détecteur n'est pas accessible durant un Run !


Evénement (Event)

Au démarrage d'un traitement, un événement contient des particules primaires

Ces primaires sont poussées dans une pile (stack) Lorsque la pile devient vide, le traitement de

l'événement est terminé La classe G4Event représente un événement. On

accède aux objets suivants à la fin du traitement : Liste des vertex primaires et des particules Ensemble des trajectoires (option) Ensembles des coups (Hits) Ensemble des digits


Trace (Track)

Une trace est un instantané de l'état d'une particule

Un pas (Step) est une information de variation pour la trace Une trace n'est pas un ensemble de pas

Une trace disparaît lorsque Elle passe au delà du volume "monde" Elle disparaît (ex : désintégration) Elle ralentit jusqu'à une énergie cinétique nulle et il

ne reste plus de processus au repos à traiter L'utilisateur décide de la tuer


Pas (Step)

Un pas possède deux points et une information de variation (delta) pour la particule (variation d'énergie lors du pas, temps de vol, etc…)

Chaque point connaît les caractéristiques des volumes. Dans le cas où un pas est limité par le bord d'un volume, le point de fin se tient sur le bord et appartient au volume suivant


Trajectoire

Une trajectoire est l'historique d'une trace. Elle contient une information sur chaque pas fait par le trace (objets de classe G4TrajectoryPoint)

Mieux vaut ne pas mettre les traces des particules secondaires d'une gerbe dans des trajectoires (pensez à la mémoire)

L'utilisateur peut créer sa propre classe de trajectoire dérivant des classes de base G4VTrajectory et G4VTrajectoryPoint. Ce faisant, on peut enregistrer n'importe quelle information additionnelle pour la simulation


Processus physiques

Trois types de base Processus au repos (ex : désintégration au repos) Processus continu (ex: ionisation) Processus discret (ex: désintégration en vol)

Le transport est aussi un processus Interaction avec les limites de volumes


Détecteur sensible et coups (hits)

Chaque volume logique peut posséder un pointeur sur un détecteur sensible

Un coup est un instantané de l'interaction physique d'une trace (ou une accumulation d'interactions d'un ensemble de traces) dans une région sensible de votre détecteur

Un détecteur sensible crée des coups (hits) en utilisant l'information donnée dans un objet G4Step. L'utilisateur doit fournir sa propre implémentation de la réponse du détecteur

Les coups (appartenant à l'objet de la classe utilisateur) sont collectés et transmis dans un objet G4Event à la fin de l'événement


Classes "Manager"

Classes de gestion d'un run, de l'interface avec le système de visualisation,… G4RunManager G4SDManager G4UIManager G4FieldManager G4VVisManager …


En pratique

Le programme "main" C'est à l'utilisateur de l'écrire Construit un G4RunManager (ou classe dérivée) Indique à cet objet les classes utilisateur

G4VUserDetectorConstruction G4VUserPhysicsList G4VUserPrimaryGeneratorAction

Peut définir le VisManager, la session (G)UI (Graphical User interface), classes d'action utilisateur optionnelles, etc…



IV.4 Caractéristiques


Le noyau

Gère la boucle d'événements Le run manager peut gérer plusieurs événements -> gère le pile-up

Tracking Découplé de la physique, tous les processus sont

gérés à travers la même interface abstraite Indépendant du type de particule Possibilité d'ajouter de nouveaux processus

physiques sans gêner le tracking


Géométrie

Description du détecteur et navigation

BaBarXMM-Newton

On peut faire des opérations sur les

solides

Et décrire des géométries complexes :

CMS


Physique

Approche : Grande variété de modèles physiques indépendants et

alternatifs Pas de "packages" ou boites noires, les utilisateurs sont en

prise directe avec la physique Validation plus aisée des résultats expérimentaux Distinction entre processus et modèle. Plusieurs modèles

pour le même processus Traitement uniforme de la physique électromagnétique et

hadronique Utilisation de bases de données expérimentales du monde

entier Validation des résultats physiques


Physique électromagnétique

Objets : Électrons et positrons Photons : , X et optiques Muons Hadrons chargés Ions

Extension vers les hautes énergies LHC, rayons cosmiques de haute énergie

Extension vers les basses énergies Applications spatiales, médicales, expériences ,

spectroscopie d'antimatière, etc…

•Diffusion multiple•Bremsstrahlung•Ionisation•Annihilation•Effet photoélectrique•Diffusion Compton•Effet Rayleigh•Conversion •Production de paires e+e-•Rayonnement synchrotron•Rayonnement de transition•Cerenkov•Réfraction•Réflexion•Absorption•Scintillation•Fluorescence•Auger (en cours)


Physique hadronique

Modèles paramétrés et basés sur les données expérimentales (data driven)

nuclear deexcitation

absorption

Stopping

MeV

Energy

Certains modèles sont complètement nouveaux :•Particules à l'arrêt•Transport de neutrons•Production d'isotopes


Autres composants

Matériaux (éléments, isotopes, alliages, composés,…)

Particules (PDG) Coups et numérisation Persistance (enregistrement des résultats) Visualisation

Lien avec OpenGL, OpenInventor, X11, Postscript, DAWN, OPACS, VRML

Interfaces utilisateur Interfaces avec des générateurs d'événements



IV.5 Applications


Physique corpusculaire ATLAS, BaBar, CMS, HARP, LHCb

Espace, astrophysique XMM, Chandra (observatoires X) Integral

Médical Brachithérapie Planning de traitement de tumeurs Dosimétrie pour mammographies Etude des dommages causés à l'ADN par les

radiations dans l'espace



IV.6 Et ce n'est pas tout…


Je ne vous ai pas tout dit…

Loin s'en faut… Plus de détails :

Site web : http://geant4.web.cern.ch/geant4/ Sur le Web :

Doc, doc, doc Sources (nécessite CLHEP)


V. Un outil d'analyse concret : ROOT

V.1 Un point de philosophie


Modèle de développement

ROOT a adopté la "philosophie" Open Source Un noyau dur de développeurs définit les grandes

orientations, à l'écoute des utilisateurs Le code est ouvert, tout le monde peut suggérer des

modifications, améliorations, etc… "Release early, release often"

Modèle "Bazaar" Les utilisateurs participent à la chasse aux bugs

Nécessité d'une grande réactivité de la part des développeurs. Les bugs sont corrigés très rapidement

Ce n'est pas contradictoire avec une analyse ou conception OO


Approche "Framework"

Définition Ensemble de catégories de classes cohérentes construites

sur des composants robustes Accent mis sur les entrées/sorties, les conteneurs et

l'interface utilisateur Besoin de contraindre la cohérence de l'application (on a vu

ce que trop de liberté donnait parfois…) Contraintes

Un framework doit être utilisé dans de nombreux endroits Si il n'est utilisé que par une seule expérience, il devient

fragile C'est un investissement à moyen et long terme


Approche Framework

Doit toujours penser à l'utilisateur : simplicité d'utilisation

Et garder les pieds sur terre !


V. ROOT

V.2 Structure générale


RTTI

Fonctionnalités d'un "framework" orienté objet

Services dePersistance

Données

Fonctions

Interface Utilisateur

C++

Java


Ce qu'il faut…

Gestion des données Très grandes quantités… qques petaoctets

Interpréteur (langage de macros) Lien simple avec le code compilé

Outils graphiques de présentation et d'analyse interactives

Outils scientifiques (histogrammes, minimisation…) Aides diverses à la programmation (conteneurs…) Connexion réseau Gestion du code source Capacités de calcul distribué ou/et parallèle


Les librairies

Plus de 350 classes

700000 lignes de code Core (4 Moctets) CINT (1.5 Moctets) Toutes les librairies (17

Moctets) En vert les librairies

chargées à la demande


Modularité

Librairies avec une structure en couches Les classes "CORE" sont toujours chargées (support

RTTI, interpréteur et entrées/sorties de base) Librairies d'application

Charge uniquement ce dont on a besoin Séparation entre objets manipulées et classes de haut

niveau agissant dessus Ex : Dans un job batch, pas besoin de charger HistPainter

(dessin des histogrammes) lorsqu'on a besoin de la librairie Hist (histogrammes)

Librairies partagées -> réduction du temps de lien Librairies ROOT peuvent être utilisées avec des

librairies externes


Interfaces abstraites

Utilisation de classes de base abstraites pour améliorer la modularité

Les librairies de bas niveau ne parlent qu'aux classes de base abstraites

Seules les applications utilisant une implémentation dans les classes dérivées devront être liées avec les librairies correspondantes

Exemple : La classe de base abstraite TVirtualPad représente l'interface graphique vers une fenêtre (canvas) ou une sous-fenêtre (pad) mais ne contient aucune implémentation (code source). L'implémentation est dans des classes dérivées Tpad et Tcanvas contenues dans les librairies libGpad et libGraf. libCore a des références vers TVirtualPad, mais seules les applications qui font réellement du graphique devront être liées avec les librairies graphiques libGpad et libGraf



V. ROOT

V.3 Interpréteur de commandes : CINT


Nécessité d'un langage interprété

GUI

Commandes

ScriptsInterprétés Scripts

Compilés


Nécessité d'un langage interprété

L'analyse de données requiert un accès efficace aux objets (données et fonctions)

Elle requiert aussi un langage de programmation puissant En mode interprété En mode compilé La transition entre mode interprété et compilé doit

se faire de façon fluide et transparente

Choix de ROOT : CINT CINT = interpréteur C/C++


CINT

Interpréteur C/C++ Ecrit par Masaharu GOTO sous licence Open

Source Reconnaît 95% du C ANSI et 90% du

standard C++ ANSI (et ça s'améliore) Peut s'interpréter lui-même (80000 lignes de

C, 5000 lignes de C++) Utilitaires de déboguage


CINT dans ROOT

CINT est utilisé dans ROOT: Comme interpréteur de commandes Comme interpréteur de scripts Pour générer un dictionnaire complet des classes Pour générer les fonctions "stubs" (voir plus loin RTTI pour ces deux derniers points)

Le langage de ligne de commandes, de scripts et de programmation sont une seule et même chose

Les gros scripts peuvent être compilés pour une performance optimale


CINT est utilisé comme un interpréteur de ligne de commande :

Et interpréteur de scripts

CINT comme interpréteur

root [0] for (int i = 0; i < 10; i++) printf(“Hello\n”)root [1] TF1 f(“f”, “sin(x)/x”, 0, 10)root [2] f.Draw()

bash$ vi script.C{ for (int i = 0; i < 10; i++) printf(“Hello\n”); TF1 f(“f”, “sin(x)/x”, 0, 10); f.Draw();}root [0] .x script.C


RTTI (Real Time Type Information)

La RTTI (Real Time Type Information) est la capacité qu'a un système de connaître en cours d'exécution les caractéristiques d'un objet (classe, structure, etc…)

Ex: Dans un programme, je veux savoir de quel type est l'objet A et si il possède la fonction "Draw"

Lorsque vous écrivez un programme, vous avez cette information dans votre tête, mais si vous récupérez un pointeur en cours d'exécution, vous n'avez à priori aucune information sur lui

Nécessité d'un dictionnaire décrivant les classes


RTTI dans ROOT

La RTTI est un élément fondamental d'un système Dans ROOT, fourni par CINT

Gestion des services d'entrées/sorties L'interpréteur est basé dessus

-> Lien entre ce qui est interprété et la fonction/classe compilée

Les classes utilisateur peuvent être analysées pour être intégrées au système, ce qui permettra de les appeler interactivement. Le code d'entrée/sortie pour ces classes peut également être généré automatiquement.

Les menus déroulants correspondant aux objets graphiques également basé sur RTTI


Intégration des classes utilisateur dans ROOT


Le préprocesseur rootcint

UserClass1.hUserClass1.h



rootcint

UserCint.C

Code C++Pour créer

la RTTI

Interface pourl'interpréteur

Streamers(fonctions d'E/S

élémentaires)


V. ROOT

V.4 Graphique : GUI (Graphical User Interface) et graphique de base


Trois interfaces utilisateur

GUI (Graphical User Interface) Fenêtres, boutons,

menus Ligne de commande

Root CINT (Interpréteur C+

+) Macros, applications,

librairies Compilateur C++ et

interpréteur


Premiers pas avec le GUI

Le BrowserROOT

Interfaceligne de commandes


"Widgets" de base


Exemple d'un GUI utilisateur

Exemple d'un GUIbasé sur les outils ROOT

On peut clicker chaque élément

L'élément Hydrogène a étésélectionné


Exemple d'un GUI dans un cadre "on-line"


Graphique 2D

Primitives de base (lignes, texte, marqueurs, …) Graphes, annotations Support LaTeX (écran et postscript) Editeur graphique Fenêtre graphique = Canvas, sous-fenêtre = Pad Interaction des objets avec le graphique via

TObject::Draw/Paint TObject::DistanceToPrimitive/ExecuteEvent


GraphiquesOrientés Objetavec actions et

sélectionsincluses


TCurlyArcTCurlyLineTWavyLine

Et autres briques pour

diagrammes de Feynman

Les formules et

diagrammes peuvent être édités avec

la souris

Support LaTeX


V. ROOT

V.5 Gestion des données

V.5.1 La persistance


Définition

La persistance est la capacité qu'a un objet à retrouver son état d'une session à l'autre Objets transitoires : en mémoire Objets persistants : savent "se sauver" sur disque


La persistance idéale

transitoire

persistant

Convertisseursautomatiques

obj1;1, obj1;2,obj1;3obj2;1, obj2;2

Evolution deschéma

automatique

Compressionefficace

Granularitécorrespondant

aux motifsd'accès

Accèsdistant

LANWAN

Formatmachine

indépendant

Pas de contraintessur

le modèle d'objet


Séquentiel/platLes entrées/sorties dans ROOT

Object in memoryObject in

memoryObject in memoryObject in

memoryObjet en mémoire

Streamer ("sérialiseur")

TFile

Objet en mémoire

ObjectGramTBuffer

Un objet transitoireest sérialisé

par son StreamerPas besoin de deux

types de classestransitoire/persistante

TWebFileServeur web

TNetFilerootd

OFileDémon RFIO

Mémoire partagée

sockets

http


Sérialiser un objet

root [0] TFile micro(”demo.root","new")

root [1] TH1F hg("hg","filled with a gaussian",100,-4,4)

root [2] hg.FillRandom("gaus",5000)

root [3] hg.Write()

root [4] micro.Map() 20000511/092959 At:64 N=92 TFile

20000511/093055 At:156 N=423 TH1F CX = 2.10

root [5] .qLa fonction Write

appelle TH1F::StreamerLa fonction Streamergénérée par rootcint

remplit un tampon (buffer)avec tous les constituants

de l'objet


Macro hsimple.C Macro qui enregistre des histogrammes et

un ntupledans un fichier ROOTroot > .x hsimple.C

Structure trèssimple du fichier


Tout ce qu'il fautsavoir pour naviguer

dans un fichier ROOT


Les fichiers ROOTpeuvent être structurés

comme un système de fichiersUnix


Fichiers déportés

Fichier localFichier déporté

accès viaun serveur Web

Fichier déportéaccès via

le démon ROOT

Accès à un fichier dans un stockage de masse

hpss, castor, via RFIO

Fichiers et répertoires Un répertoire (directory) contient une liste d'objets nommés Un fichier peut contenir une hiérarchie de répertoires (à la

Unix) Les fichiers ROOT sont machine indépendants Compression des données intégrée

Support pour les fichiers locaux ou déportés TFile f1("myfile.root") TFile f2("http://pcbrun.cern.ch/Renefile.root") TFile f3("root://cdfsga.fnal.gov/bigfile.root") TFile f4("rfio://alice/run678.root")


V. ROOT


V.5.2 Ntuples et arbres


Ntuples et arbres (Trees)

Ntuples Ensemble d'entrées comprenant chacune une ou plusieurs

valeurs numériques = très grand tableau Peut faire des des corrélations entre les colonnes Support des Ntuples à la PAW, peut importer des histos et

ntuples au format PAW Arbres (Trees)

Extension des Ntuples pour les objets Chaque entrée peut correspondre à un événement Recueil (collection) de branches (chaque branche a son

propre tampon (buffer) Peut entrer un événement partiellement rempli Peut avoir plusieurs arbres en parallèle

Chaîne (Chain) = Recueil d'arbres


Dis, ça sert à quoi, un arbre ?

Tout objet qui dérive de TObject peut être écrit dans un fichier avec une clé (Key) associée via object.Write()

Mais chaque clé produit un excès de 60 octets dans la structure du répertoire en mémoire

object.Write() est adapté pour des objets "esseulés" tels des histogrammes, objets du détecteur, étalonnage mais pas pour des objets "événements"


Dis, ça sert à quoi, un arbre ?

Les arbres ont été conçus pour contenir de très grands ensembles d'objets. L'excès en mémoire ne dépasse pas en général 4 octets par entrée

L'accès se fait de façon séquentielle ou aléatoire (l'accès séquentiel est le plus efficace)

Les arbres ont des branches et des feuilles. On peut lire seulement un sous ensemble de toutes les branches. Cela peut grandement accélérer l'analyse de données

Un Ntuple est un cas particulier d'arbre Les arbres sont conçus pour contenir des objets

complexes


Remarques importantes

Les fichiers ROOT sont autonomes : Les objets dans les fichiers ROOT (par ex. les

arbres) peuvent référencer d'autres fichiers (arbres)

On peut lire un arbre sans les classes correspondant aux objets qu'il contient

Le dictionnaire est sauvegardé en tant qu'objet dans la structure arbre/branche

Il est possible de générer un squelette de code automatiquement avec TTree::MakeClass


Création d'un arbre

Un arbre est une liste de branches Constructeur de la classe Ttree :

Nom de l'arbre (par ex. "myTree") Titre de l'arbre Taille maximale totale des tampons

(buffers) gardés en mémoire vive(défaut : 64 Mo)

TTree *tree = new TTree("T","A ROOT tree");


Ajout d'une branche

Nom de la branche Nom de la classe des objets que la

branche va contenir Adresse du pointeur vers l'objet à

enregistrer (dérive de TObject) Taille du tampon (défaut = 32000) Niveau de scission (split level), défaut = 1

Event *event = new Event();myTree->Branch(”eBranch","Event",&event,64000,1);


Scission d'une branche

Niveau de scissionsplit level = 0

Niveau de scissionsplit level = 1

Exemple:

tree->Branch("EvBr","Event",&ev,64000,0);


Ajout d'une branche avec une liste de variables

Nom de la branche Adresse du premier élément

d'une structure Leaflist = noms et types de

toutes les variables Ordonner les variables selon

leur taille

ExampleTBranch *b = tree->Branch ("Ev_Branch",&event,

"ntrack/I:nseg:nvtex:flag/i:temp/F");


Remplissage d'un arbre

Créer une boucle "for" Créer des objets Event Appeler la méthode Fill() de l'arbre

myTree->Fill()


Ecriture du fichier

La commande TFile::Write() Ecrit les histogrammes et les arbres Write est nécessaire pour écrire l'en-tête du fichier

hfile->Write()


Exemple complet de création d'un arbre

Quelques lignesde code de création

d'un arbre pour des structures

qui peuvent êtretrès complexes


Le "Browser" parcoureur ? brouteur ? feuilleteur ?

8 branches de l'arbre "T"

8 feuilles de la brancheElectrons


Les Chaînes (Chains)

Scénario : Réaliser une analyse sur de multiples fichiers ROOT. Tous les fichiers ont la même structure et le même arbre

Des Chaînes sontdes recueils

de chaînes de fichiers


Chaînes de fichiers

Un TChain est un recueil (collection) d'arbres Même syntaxe pour les chaînes et les arbres

root > .x h1chain.C root > chain.Process("h1analysis.C")

{ //creates a TChain to be used by the h1analysis.C class //the symbol H1 must point to a directory where the H1 data sets //have been installed TChain chain("h42"); chain.Add("$H1/dstarmb.root"); chain.Add("$H1/dstarp1a.root"); chain.Add("$H1/dstarp1b.root"); chain.Add("$H1/dstarp2.root");}


Structure conçue pour supporter de

très grosses bases de données


Analyse de données dans un arbre

Via TTree::Draw(), à la PAW, par ex. root > tree.Draw("px","pt>1.2")

Via click dans le TBrowser Via la classe spécialisée TTreeViewer Via la même classe que celle qui a généré

l'arbre Via un code généré par TTree::MakeClass Via un code généré par TTree::MakeSelector


Analyse "interactive" Dans TBrowser :un double click

pour histogrammerune feuille

TTreeViewer :Coupures complexes,listes d'événements,

vues 1D, 2D, 3D,traitement en parallèle


Générateurs de code automatiques

On doit pouvoir lire les données sans les classes qui ont servi à les créer. Ces classes peuvent ne plus être disponibles après un certain temps

ROOT fournit deux utilitaires pour générer un squelette de classe qui puisse lire les données, en préservant les attributs de nom, de type et de structure. TTree::MakeClass TTree::MakeSelector


TTree::MakeClass

tree.MakeClass(“myClass”); génère deux fichiers: myClass.h et myClass.C

myClass.h contient la déclaration de classe et le code des fonctions membres qui sont "sélection invariantes".

myClass.C contient un exemple de boucle vide ou l'on peut insérer le code d'analyse

Utilisation: root > .L myClass.C or .L myClass.C++ root > myClass xx; root > xx.Loop();

Utilisation de l'interpréteur

Utilisation du compilateur natifLe fichier myClass.Cest automatiquement

compiléet lié !!


TTree::MakeSelector

tree.MakeSelector(“myClass”); génère deux fichiers: myClass.h and myClass.C qui peuvent être utilisées dans un système parallèle comme PROOF. La boucle d'événements n'est plus sous le contrôle de l'utilisateur.

myClass.h contient la déclaration de classe et le code des fonctions membres qui sont "sélection invariantes".

myClass.C contient le squelette de 4 fonctions: Begin, ProcessCut, ProcessFill, Terminate.

Utilisation: root > tree.Process(“myClass.C”); root > chain.Process(“myClass.C++”);

La macro estautomatiquementcompilée et liée…


V. ROOT


V.5.3 Approche base de données dans ROOT


Les tendances

Mettre tout dans des systèmes de gestion de bases de données orientées objet

Encore beaucoup de travail pour éviter les écueils (trop gros fichiers, transferts de données non optimisés, etc…)


Les tendances "à la sauce ROOT"

Met les données écrites une seule fois (typiquement les données brutes, mais également toutes les données non destinées à être modifiées) dans un système de stockage d'objets

Utilise les RDBMS (Relational Database Management System) comme Oracle ou MySQL pour

Catalogues Run/Evénements Géométrie, étalonnages Par ex. interface ROOT<-> Oracle

Utilise le mode scindé (split) de ROOT pour faire l'analyse de physique (efficacité de l'accès)

ROOT Oracle

Combine les deux technologies


histograms

Etalonnages

Géométries

CatalogueRun/Fichiers

Trees

Stockage d'événements

FichiersROOT

OracleMySQL


V. ROOT

V.6 Graphique : présentation des données 1, 2 et 3D


Représentation graphique des objets

Les objets de ROOT dérivent de la classe de base TObject

Cette classe possède une fonction Draw(), surdéfinie dans les classes dérivées

Chaque objet se dessine lui même Ce que l'on voit sur l'écran est l'objet lui-

même et non une copie -> si on modifie la représentation de l'objet à

l'écran, on modifie également l'objet en mémoire


Options graphiques 1D

Tout objet dans le canvaspeut être clické et édité



Plusieurs vuesdifférentes

du même objet



Le nombre et le typedes contours peut-

êtremodifié avec la

souris.Chaque contour

est un objet



Tous ces graphiques

peuvent être

tournés avec la souris



Même image sur l'écran etsur une sortie Postscript


V. ROOT

V.7 Outils "physiques"


Outils "physiques"

Graphes Fonctions Histogrammes 1D, 2D, 3D Minimisations


Graphes

Un ensemble de points (x,y) peut être représenté par un graphe (TGraph)

Les options graphiques supportées sont celles correspondant au cas 1D


Fonctions

Fonctions 1D, 2D et 3D (classes TF1,2,3) Un objet TF1 est une fonction à 1 dimension définie entre un

minimum et un maximum La fonction peut être une fonction simple ou une fonction

précompilée Elle peut avoir des

paramètres associés Exemple de création et

affichage d'une fonction TF1 f1("f1","sin(x)/x",0,10); f->Draw();


Les classes d'histogrammes

1-Dim

2-Dim

3-Dim

Pas dans PAW/Hbook


Sauvegarde/Lecture d'un histogramme de/vers un fichier ROOT

Les lignes suivantes créent un fichier Root et y sauvent un histogramme

TFile f("histo.root","new"); TH1F h1("hgaus","histo gaussienne",100,-3,3); h1.FillRandom("gaus",10000); h1.Write();

Pour lire cet histogramme dans une autre session ROOT, effectuer : TFile f("histos.root"); TH1F *h = (TH1F*)f.Get("hgaus");

On peut sauvegarder TOUS les histos en mémoire dans le fichier : f.Write();


Remplissage des histogrammes

Un histogramme est rempli à l'aide de commandes telles que : h1->Fill(x); h1->Fill(x,w); //remplissage avec poids h2->Fill(x,y); h2->Fill(x,y,w); h3->Fill(x,y,z); h3->Fill(x,y,z,w);

Si TH1::Sumw2 a été appelé avant le remplissage, la somme des carrés des poids sera également sauvegardée

Il est possible d'incrémenter directement un canal particulier via TH1::AddBinContent() ou remplacer le contenu existant par TH1::SetBinContent()

L'accès au contenu d'un canal (bin) donné se fait par : Double_t bincontent = h->GetBinContent();


"Binning" et "rebinning" automatique

Lorsque l'option de binning automatique est sélectionnée, la fonction Fill va étendre les limites des axes pour les adapter à la valeur passée en argument

Ce binning automatique est utilisé dans TTree::Draw pour histogrammer les variables d'un arbre sans connaître l'étendue de leurs valeurs.

Un histogramme peut être "rebinné" (changement du nombre de canaux) à l'aide de TH1::Rebin()

Les erreurs sont recalculées durant ce processus


Incertitudes associées

Par défaut, pour chaque canal, on calcule la somme des poids au remplissage

On peut également appeler TH1::Sumw2 pour forcer la sauvegarde de la somme des carrés des poids pour chaque canal

Si Sumw2 a été appelé, l'incertitude par canal (bin) est calculée comme sqrt(somme des carrés des poids), sinon elle est mise à sqrt(contenu du canal)

Pour obtenir l'incertitude correspondant à un canal donné, faire :

Double_t err = h->GetBinError(bin);


Opérations sur les histogrammes

Un grand nombre d'opérations sont implémentées sur les histogrammes :

Ajout, produit, quotient d'un histogramme par celui qui est courant

Ajout, produit, quotient de deux histogrammes avec des coefficients et sauvegarde dans l'histogramme courant

Ajout, produit, quotient d'un histogramme par une fonction Les incertitudes sont recalculées en supposant des

histogrammes indépendants Les opérateurs +, -, *, / sont supportés


Projections

Sont prévues : La projection 1D d'un histogramme 2D ou Profile.

Voir TH2::ProjectionX,Y, TH2::ProfileX,Y, TProfile::ProjectionX

Une projection 1D, 2D ou un profile d'un histo 3D. Voir TH3::ProjectionZ, TH3::Project3D

On peut ajuster ces projections par TH2::FitSlicesX,Y, TH3::FitSlicesZ


Nombres aléatoires et histogrammes

Plusieurs générateurs de nombres aléatoires sont prévus. Voir classes TRandom, TRandom2,3

On peut remplir aléatoirement un histogramme par TH1::FillRandom en utilisant

Une fonction analytique de type TF1 existante Un autre histogramme (toutes les dimensions)

Exemple : les deux lignes suivantes créent et remplissent un histogramme de 10000 entrées correspondant à une distribution gaussienne (moyenne = 0, sigma = 1 par défaut) :

TH1F h1("h1","histo gaussienne",100,-3,3); h1.FillRandom("gaus",10000);

TH1::GetRandom est utilisé pour renvoyer un nombre aléatoire distribué selon le contenu d'un histogramme


Dessin et affichage des histogrammes

Lorsque vous appelez la méthode Draw (TH1::Draw()) d'un histogramme pour la première fois, un objet THistPainter est créé et son pointeur sauvé comme donnée membre de l'objet histogramme

La classe THistPainter est spécialisée dans le dessin des histogrammes. Elle a été séparée de l'histogramme lui-même pour permettre l'utilisation des objets histogrammes sans la surcharge due au graphique (programme batch par ex.)

Lorsqu'un histogramme est modifié, pas besoin d'appeler Draw() de nouveau. Son image est rafraîchie lorsque le Pad est rafraîchi

On peut dessiner le même histo dans des pads différents avec des options graphiques différentes

Lorsqu'on détruit un histo, son image est automatiquement enlevée du pad


Ajustement (fit) des histogrammes avec Minuit

Les histogrammes (1D, 2D et 3D et Profiles) peuvent être ajustés avec une fonction utilisateur via TH1::Fit.

Deux algorithmes d'ajustement sont possibles : Méthode du chi carré et max vraisemblance (Log Likelihood)

Les fonctions utilisateur peuvent être : Standard : gaus, landau, expo, poln Combinaison de fonctions standard : poln+gaus Une fonction C++ interprétée ou précompilée

Lors de l'ajustement d'un histogramme, la fonction résultante et ses paramètres est ajoutée à la liste de fonctions de cet histogramme. Si l'histogramme est sauvé, cette liste également

On peut récupérer les paramètres de la fonction/ajustement à l'aide de commandes telles que :

Double_t chi2 = myfunc->GetChisquare(); Double_t par0 = myfunc->GetParameter(0); // valeur 1er paramètre Double_t err0 = myfunc->GetParError(0); // erreur 1er paramètre


Exemple d'ajustement

Voir FittingDemo.C

Macro non nommée fitf.C

Macro nommée

Tourne FittingDemo.CPlus d'infos:http://root.cern.ch/root/html/examples/fit1.C.htmlhttp://root.cern.ch/root/html/examples/myfit.C.htmlhttp://root.cern.ch/root/html/examples/backsig.C.html


Combinaison de fonctions

y(E) = a1 + a2E + a3E2 + AP ( / 2 )/( (E-)2 + (/2)2)

background lorenzianPeakpar[0] = a1 par[0] = AP

par[1] = a2 par[1] = par[2] = a3 par[2] =

fitFunction = background (x, par ) + lorenzianPeak (x, &par[3])par[0] = a1 par[1] = a2 par[2] = a3

par[3] = Ap

par[4] = par[5] =

On peut minimiser des fonctions avec un grand nombre de

paramètres (> 200)Pas de limitations


Fonctions associées

Un ou plusieurs objets (typiquement un TF1*) peuvent être ajoutés à la liste de fonctions associées à un histogramme

Lorsque TF1::Fit est appelé, la fonction résultante est ajoutée à la liste Soit un histogramme h, on peut récupérer une fonction associée par :

TF1* myfunc = h->GetFunction("myfunc");


V. ROOT

V.8 Outils "techniques"


Outils techniques

Conteneurs = objets destinés à contenir d'autres objets (tableaux, listes, cartes,…) Fonctionnalités globalement équivalentes à STL On parcourt le contenu à l'aide d'un "itérateur" Certains conteneurs sont particulièrement

efficaces dans le cadre ROOT : TClonesArray


V. ROOT

V.9 Calcul parallèle


Calcul parallèle dans ROOT : PROOF

PROOF est une implémentation d'un système de calcul parallèle dans ROOT

Il permet le traitement en parallèle de chaînes d'arbres sur des grappes de machines hétérogènes

Ce développement se fait avec en arrière plan les développements récents de GRID

GRID = concept d'un ensemble de machines dispersées sur la terre devant traiter une très grande quantité de données en parallèle Exemple simpliste : projet SETI@home


ROOT/PROOF et les GRIDs

SélectionParamètres

DB1

DB4

DB5

DB6

CPU

Local

Remote

Procédure

Proc.C

Proc.C

Proc.C

Proc.C

Proc.C

PROOF

CPU

CPU

CPU

CPU

CPU

TagDB

RDB

DB3

DB2

Autant que possible,transférer la tâchevers les donnéeset non l'inverse


La "Parallel ROOT Facility"

Les serveurs esclaves forment la partie active, demandant au serveur maître du travail lorsqu'ils sont prêts

-> envoi de paquets de données par le maître Paramètres cruciaux

la taille des paquets envoyés Au maître de n'envoyer à l'esclave que ce qu'il peut traiter (ni

trop, ni trop peu). Ceci se décide en fonction du comportement précédent de l'esclave (vitesse, crash, etc…)

La localisation des données Au maître de faire attention à envoyer du travail sur des

données qui sont proches de l'esclave (si possible sur l'esclave lui-même)


Diagramme de traitement des données

Initialisation

Traitement

Traitement

Traitement

Traitement

Attentecommande

Esclave 1Tree->Draw()

Gén

érat

eur

de

paq

uet

s Initialisation

Traitement

Traitement

Traitement

Traitement

Attentecommande

Esclave NMaîtreTree->Draw()

GetNextPacket()

GetNextPacket()

GetNextPacket()

GetNextPacket()

GetNextPacket()

GetNextPacket()

GetNextPacket()

GetNextPacket()

SendObject(histo)SendObject(histo)

Sommehistogrammes

Affichehistogrammes

0,100

200,100

340,100

490,100

100,100

300,40

440,50

590,60


Exemple d'une session PROOF

root [0] .! ls -l run846_tree.root-rw-r-r-- 1 rdm cr 598223259 Feb 1 16:20 run846_tree.root

root [1] TFile f("run846_tree.root")

root [2] gROOT->Time()

root [3] T49->Draw("fPx")Real time 0:0:11, CP time 10.860

root [4] gROOT->Proof()*** Proof slave server : pcna49a.cern.ch started ****** Proof slave server : pcna49b.cern.ch started ****** Proof slave server : pcna49c.cern.ch started ****** Proof slave server : pcna49d.cern.ch started ****** Proof slave server : pcna49e.cern.ch started ***Real time 0:0:4, CP time 0.140

root [5] T49->Draw("fPx")Real time 0:0:3, CP time 0.240


V. ROOT

V.10 Documentation automatique


Documentation

La documentation est très importante dans tous les grands projets Pour l'utilisateur : Manuels, exemples, etc… Pour le développeur : documentation du code, de

la structure, etc… Mais documenter du code est une tâche

ardue -> documentation automatique à partir du

code source


Documentation automatique

ROOT dispose d'un mécanisme de documentation automatique basé sur le dictionnaire généré par l'interpréteur à partir des en-têtes de classe (fichiers xxx.h)

Produit des pages web, avec liens permettant de naviguer dans le code

Dictionnaire CINTet sources

xxx.h, xxx.cc

PagesHTMLTHtml


Allez voir vous-même http://root.cern.ch/root/htmldoc/ClassIndex.html


V. ROOT

V.11 Et ce n'est pas tout…


Je ne vous ai pas tout dit…

Loin s'en faut… Plus de détails :

Site web : http://root.cern.ch Manuel ROOT

Sur le Web : Doc, doc, doc Source et binaires pour une trentaine de

combinaisons compilateurs/plateformes

Documents

Simulation, modélisation, traitement des données