Simulation, modélisation, traitement des données

Présentation au sujet: "Simulation, modélisation, traitement des données"— Transcription de la présentation:

1 Simulation, modélisation, traitement des données
Une approche pragmatique D. Buskulic, Maubuisson 2001

2 I.1 Contraintes sur les outils de Physique Corpusculaire
I. Généralités I.1 Contraintes sur les outils de Physique Corpusculaire D. Buskulic, Maubuisson 2001

3 Quantité de données à traiter
1 Teraoctet à quelques Petaoctets/an ! 1015 octets 1000 Teraoctets bandes d'aujourd'hui DVD RAM double face 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) D. Buskulic, Maubuisson 2001

4 Ca va plus vite que la loi de Moore
Données Babar D. Buskulic, Maubuisson 2001

5 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 D. Buskulic, Maubuisson 2001

6 Quantité de calculs nécessaires
Grande puissance de calcul nécessaire pour simuler/reconstruire/analyser les données 1000 à PC d'aujourd'hui (fermes) Importance du calcul parallèle Futur : calcul distribué D. Buskulic, Maubuisson 2001

7 I.2 Critères et fonctionnalités à respecter
I. Généralités I.2 Critères et fonctionnalités à respecter D. Buskulic, Maubuisson 2001

8 Comment faisait-on une analyse ?
Modèle "Batch" Détecteur Données Traitement batch histos… D. Buskulic, Maubuisson 2001

9 Détecteur ou simulation
Un meilleur modèle Raw Data coups ADC… Détecteur ou simulation une fois DST traces, etc… Reconstruction Ntuple valeurs calculées Analyse histos… un grand nombre de fois Mais ca ne suffit pas pour traiter les données LHC ! D. Buskulic, Maubuisson 2001

10 Tâches à effectuer : exemple
Recette : 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 Et ceci 10 millions de fois ! D. Buskulic, Maubuisson 2001

11 Reste à étudier la physique, mesurer, publier…
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 D. Buskulic, Maubuisson 2001

12 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) D. Buskulic, Maubuisson 2001

13 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 D. Buskulic, Maubuisson 2001

14 Influence sur les modèles d'environnement de travail
Modèles d'environnements de travail : Composants Boite à outils Services D. Buskulic, Maubuisson 2001

15 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 D. Buskulic, Maubuisson 2001

16 II. Programmation et langages Orientés Objet
II.1 Motivations D. Buskulic, Maubuisson 2001

17 Complexité des briques élémentaires
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 ? Complexité des briques élémentaires Complexité des tâches D. Buskulic, Maubuisson 2001

18 On peut essayer d'adapter les vieux outils
Mais il faut parfois faire des sauts conceptuels D. Buskulic, Maubuisson 2001

19 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 Raw DST Ntuples Histos D. Buskulic, Maubuisson 2001

20 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… D. Buskulic, Maubuisson 2001

21 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 D. Buskulic, Maubuisson 2001

22 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 ( ): 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. D. Buskulic, Maubuisson 2001

23 II. Programmation et langages Orientés Objet
II.2 Principe et concepts de base D. Buskulic, Maubuisson 2001

24 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 D. Buskulic, Maubuisson 2001

25 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 D. Buskulic, Maubuisson 2001

26 II. Programmation et langages Orientés Objet
II.3 Classes, Objets et Encapsulation D. Buskulic, Maubuisson 2001

27 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 "p+no 23" est un objet D. Buskulic, Maubuisson 2001

28 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 D. Buskulic, Maubuisson 2001

29 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(); … D. Buskulic, Maubuisson 2001

30 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; D. Buskulic, Maubuisson 2001

31 Classes et objets Les données membres d'une classe ont une relation d'appartenance (possède un) D. Buskulic, Maubuisson 2001

32 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 D. Buskulic, Maubuisson 2001

33 Encapsulation Les changements de l'implémentation interne ne doivent pas modifier la façon dont on accède et utilise la classe extérieurement 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éthodes publiques D. Buskulic, Maubuisson 2001

34 II. Programmation et langages Orientés Objet
II.4 Hiérarchies de classes et héritage D. Buskulic, Maubuisson 2001

35 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é D. Buskulic, Maubuisson 2001

36 L'héritage correspond à une notion d'identité ("est un")
Hiérarchie de classes L'héritage correspond à une notion d'identité ("est un") D. Buskulic, Maubuisson 2001

37 TObject Segment Momentum Event Track Vertex InterceptAtVertex
possède un est un possède un Event Track MassSquared possède un possède un possède un possède un Vertex InterceptAtVertex D. Buskulic, Maubuisson 2001

38 II. Programmation et langages Orientés Objet
II.5 Abstraction et polymorphisme D. Buskulic, Maubuisson 2001

39 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 D. Buskulic, Maubuisson 2001

40 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 D. Buskulic, Maubuisson 2001

41 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) D. Buskulic, Maubuisson 2001

42 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 ! D. Buskulic, Maubuisson 2001

43 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". D. Buskulic, Maubuisson 2001

44 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 Derive() {;} main() Base* a = new Derive(); a->Affiche(1.0); -> affiche "Int" ! D. Buskulic, Maubuisson 2001

45 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… D. Buskulic, Maubuisson 2001

46 II. Programmation et langages Orientés Objet
II.6 C++ et Java D. Buskulic, Maubuisson 2001

47 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 ? D. Buskulic, Maubuisson 2001

48 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" D. Buskulic, Maubuisson 2001

49 Java : 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 D. Buskulic, Maubuisson 2001

50 Java : avantages Portabilité Robustesse
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 D. Buskulic, Maubuisson 2001

51 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 D. Buskulic, Maubuisson 2001

52 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++ D. Buskulic, Maubuisson 2001

53 III. Panorama des outils de simulation et d'analyse
disponibles et à venir… D. Buskulic, Maubuisson 2001

54 Outils de simulation Passé, présent : Futur :
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++ D. Buskulic, Maubuisson 2001

55 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… D. Buskulic, Maubuisson 2001

56 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 D. Buskulic, Maubuisson 2001

57 Anaphe Ex LHC++ Principalement basé sur des produits commerciaux
D. Buskulic, Maubuisson 2001

58 Open Scientist Extrêmement modulaire (pb de cohérence ?)
Essaye de récupérer et intégrer des codes libres existants D. Buskulic, Maubuisson 2001

59 ROOT On va en reparler de façon extensive…
D. Buskulic, Maubuisson 2001

60 IV. Exemple d'un outil de simulation : GEANT 4
IV.1 Introduction D. Buskulic, Maubuisson 2001

61 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 D. Buskulic, Maubuisson 2001

62 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 D. Buskulic, Maubuisson 2001

63 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é D. Buskulic, Maubuisson 2001

64 GEANT4 Collaboration internationale
Adoption de méthodes d'ingénierie logicielle (OOA et OOD) Choix de l'orientation objet et C++ D. Buskulic, Maubuisson 2001

65 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 D. Buskulic, Maubuisson 2001

66 GEANT4 : Performance GEANT4 : Flexibilité
"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 D. Buskulic, Maubuisson 2001

67 IV. Exemple d'un outil de simulation : GEANT 4
IV.2 Présentation D. Buskulic, Maubuisson 2001

68 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) D. Buskulic, Maubuisson 2001

69 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 D. Buskulic, Maubuisson 2001

70 IV. Exemple d'un outil de simulation : GEANT 4
IV.3 Concepts de base D. Buskulic, Maubuisson 2001

71 Concepts de base Run, Event, Track, Step, Trajectory
Processus physiques Partie sensible d'un détecteur et coups Classes Manager D. Buskulic, Maubuisson 2001

72 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 ! D. Buskulic, Maubuisson 2001

73 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 D. Buskulic, Maubuisson 2001

74 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 D. Buskulic, Maubuisson 2001

75 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 D. Buskulic, Maubuisson 2001

76 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 D. Buskulic, Maubuisson 2001

77 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. Buskulic, Maubuisson 2001

78 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 D. Buskulic, Maubuisson 2001

79 Classes "Manager" Classes de gestion d'un run, de l'interface avec le système de visualisation,… G4RunManager G4SDManager G4UIManager G4FieldManager G4VVisManager … D. Buskulic, Maubuisson 2001

80 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… D. Buskulic, Maubuisson 2001

81 IV. Exemple d'un outil de simulation : GEANT 4
IV.4 Caractéristiques D. Buskulic, Maubuisson 2001

82 Le noyau Gère la boucle d'événements Tracking
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 D. Buskulic, Maubuisson 2001

83 On peut faire des opérations sur les solides
Géométrie Description du détecteur et navigation On peut faire des opérations sur les solides Et décrire des géométries complexes : XMM-Newton BaBar CMS D. Buskulic, Maubuisson 2001

84 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 D. Buskulic, Maubuisson 2001

85 Physique électromagnétique
Diffusion multiple Bremsstrahlung Ionisation Annihilation Effet photoélectrique Diffusion Compton Effet Rayleigh Conversion g Production de paires e+e- Rayonnement synchrotron Rayonnement de transition Cerenkov Réfraction Réflexion Absorption Scintillation Fluorescence Auger (en cours) Objets : Électrons et positrons Photons : g, 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 n, spectroscopie d'antimatière, etc… D. Buskulic, Maubuisson 2001

86 Physique hadronique Modèles paramétrés et basés sur les données expérimentales (data driven) nuclear deexcitation absorption Stopping p MeV Energy Certains modèles sont complètement nouveaux : Particules à l'arrêt Transport de neutrons Production d'isotopes D. Buskulic, Maubuisson 2001

87 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 D. Buskulic, Maubuisson 2001

88 IV. Exemple d'un outil de simulation : GEANT 4
IV.5 Applications D. Buskulic, Maubuisson 2001

89 Physique corpusculaire Espace, astrophysique
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 D. Buskulic, Maubuisson 2001

90 IV. Exemple d'un outil de simulation : GEANT 4
IV.6 Et ce n'est pas tout… D. Buskulic, Maubuisson 2001

91 Je ne vous ai pas tout dit…
Loin s'en faut… Plus de détails : Site web : Sur le Web : Doc, doc, doc Sources (nécessite CLHEP) D. Buskulic, Maubuisson 2001

92 V. Un outil d'analyse concret : ROOT
V.1 Un point de philosophie D. Buskulic, Maubuisson 2001

93 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 D. Buskulic, Maubuisson 2001

94 Approche "Framework" Définition Contraintes
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 D. Buskulic, Maubuisson 2001

95 Approche Framework Et garder les pieds sur terre !
Doit toujours penser à l'utilisateur : simplicité d'utilisation Et garder les pieds sur terre ! D. Buskulic, Maubuisson 2001

96 V. ROOT V.2 Structure générale D. Buskulic, Maubuisson 2001

97 Fonctionnalités d'un "framework" orienté objet
Services de Persistance C++ RTTI Données Fonctions Java Interface Utilisateur D. Buskulic, Maubuisson 2001

98 Ce qu'il faut… Gestion des données Interpréteur (langage de macros)
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 D. Buskulic, Maubuisson 2001

99 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 D. Buskulic, Maubuisson 2001

100 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 D. Buskulic, Maubuisson 2001

101 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 D. Buskulic, Maubuisson 2001

102 D. Buskulic, Maubuisson 2001

103 V.3 Interpréteur de commandes : CINT
V. ROOT V.3 Interpréteur de commandes : CINT D. Buskulic, Maubuisson 2001

104 Nécessité d'un langage interprété
GUI Scripts Interprétés Scripts Compilés Commandes D. Buskulic, Maubuisson 2001

105 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++ D. Buskulic, Maubuisson 2001

106 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 D. Buskulic, Maubuisson 2001

107 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 D. Buskulic, Maubuisson 2001

108 CINT comme interpréteur
CINT est utilisé comme un interpréteur de ligne de commande : Et interpréteur de scripts 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 D. Buskulic, Maubuisson 2001

109 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 D. Buskulic, Maubuisson 2001

110 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 D. Buskulic, Maubuisson 2001

111 Intégration des classes utilisateur dans ROOT
D. Buskulic, Maubuisson 2001

112 Le préprocesseur rootcint
UserCint.C Code C++ Pour créer la RTTI Interface pour l'interpréteur Streamers (fonctions d'E/S élémentaires) UserClass1.h UserClass1.h UserClass1.h UserClass1.h UserClass1.h UserClass1.h rootcint D. Buskulic, Maubuisson 2001

113 V.4 Graphique : GUI (Graphical User Interface) et graphique de base
V. ROOT V.4 Graphique : GUI (Graphical User Interface) et graphique de base D. Buskulic, Maubuisson 2001

114 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 D. Buskulic, Maubuisson 2001

115 Premiers pas avec le GUI
Le Browser ROOT Interface ligne de commandes D. Buskulic, Maubuisson 2001

116 "Widgets" de base D. Buskulic, Maubuisson 2001

117 Exemple d'un GUI utilisateur
Exemple d'un GUI basé sur les outils ROOT On peut clicker chaque élément L'élément Hydrogène a été sélectionné D. Buskulic, Maubuisson 2001

118 Exemple d'un GUI dans un cadre "on-line"
D. Buskulic, Maubuisson 2001

119 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 D. Buskulic, Maubuisson 2001

120 Graphiques Orientés Objet avec actions et sélections incluses
D. Buskulic, Maubuisson 2001

121 Support LaTeX TCurlyArc TCurlyLine TWavyLine
Les formules et diagrammes peuvent être édités avec la souris TCurlyArc TCurlyLine TWavyLine Et autres briques pour diagrammes de Feynman D. Buskulic, Maubuisson 2001

122 V.5 Gestion des données V.5.1 La persistance
V. ROOT V.5 Gestion des données V.5.1 La persistance D. Buskulic, Maubuisson 2001

123 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 D. Buskulic, Maubuisson 2001

124 La persistance idéale Accès distant Evolution de schéma automatique
Pas de contraintes sur le modèle d'objet Evolution de schéma automatique transitoire Convertisseurs automatiques Granularité correspondant aux motifs d'accès LAN WAN persistant Compression efficace Format machine indépendant obj1;1, obj1;2,obj1;3 obj2;1, obj2;2 D. Buskulic, Maubuisson 2001

125 Les entrées/sorties dans ROOT
Séquentiel/plat Un objet transitoire est sérialisé par son Streamer Pas besoin de deux types de classes transitoire/persistante Object in memory Object in memory Object in memory Streamer ("sérialiseur") Object in memory Objet en mémoire Mémoire partagée Objet en mémoire TWebFile Serveur web http ObjectGram TBuffer OFile Démon RFIO TNetFile rootd sockets TFile D. Buskulic, Maubuisson 2001

126 Sérialiser un objet La fonction Write appelle TH1F::Streamer
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() / At: N= TFile / At: N= TH1F CX = 2.10 root [5] .q La fonction Write appelle TH1F::Streamer La fonction Streamer générée par rootcint remplit un tampon (buffer) avec tous les constituants de l'objet D. Buskulic, Maubuisson 2001

127 Macro hsimple.C Structure très simple du fichier
Macro qui enregistre des histogrammes et un ntuple dans un fichier ROOT root > .x hsimple.C Structure très simple du fichier D. Buskulic, Maubuisson 2001

128 Tout ce qu'il faut savoir pour naviguer dans un fichier ROOT
D. Buskulic, Maubuisson 2001

129 Les fichiers ROOT peuvent être structurés comme un système de fichiers Unix
D. Buskulic, Maubuisson 2001

130 Accès à un fichier dans un stockage de masse
Fichiers déportés 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(" TFile f3("root://cdfsga.fnal.gov/bigfile.root") TFile f4("rfio://alice/run678.root") Fichier déporté accès via un serveur Web Fichier local Fichier déporté accès via le démon ROOT Accès à un fichier dans un stockage de masse hpss, castor, via RFIO D. Buskulic, Maubuisson 2001

131 V.5 Gestion des données V.5.2 Ntuples et arbres
V. ROOT V.5 Gestion des données V.5.2 Ntuples et arbres D. Buskulic, Maubuisson 2001

132 Ntuples et arbres (Trees)
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 D. Buskulic, Maubuisson 2001

133 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" D. Buskulic, Maubuisson 2001

134 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 D. Buskulic, Maubuisson 2001

135 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 D. Buskulic, Maubuisson 2001

136 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"); D. Buskulic, Maubuisson 2001

137 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); D. Buskulic, Maubuisson 2001

138 Scission d'une branche Niveau de scission split level = 0
Exemple: tree->Branch("EvBr","Event",&ev,64000,0); D. Buskulic, Maubuisson 2001

139 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 Example TBranch *b = tree->Branch ("Ev_Branch",&event, "ntrack/I:nseg:nvtex:flag/i:temp/F"); D. Buskulic, Maubuisson 2001

140 Remplissage d'un arbre Créer une boucle "for" Créer des objets Event
Appeler la méthode Fill() de l'arbre myTree->Fill() D. Buskulic, Maubuisson 2001

141 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() D. Buskulic, Maubuisson 2001

142 Exemple complet de création d'un arbre
Quelques lignes de code de création d'un arbre pour des structures qui peuvent être très complexes D. Buskulic, Maubuisson 2001

143 Le "Browser" parcoureur ? brouteur ? feuilleteur ?
8 feuilles de la branche Electrons 8 branches de l'arbre "T" D. Buskulic, Maubuisson 2001

144 Des Chaînes sont des recueils de chaînes de fichiers
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 sont des recueils de chaînes de fichiers D. Buskulic, Maubuisson 2001

145 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"); } D. Buskulic, Maubuisson 2001

146 Structure conçue pour supporter de très grosses bases de données
D. Buskulic, Maubuisson 2001

147 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 D. Buskulic, Maubuisson 2001

148 Dans TBrowser : un double click pour histogrammer une feuille
Analyse "interactive" Dans TBrowser : un double click pour histogrammer une feuille TTreeViewer : Coupures complexes, listes d'événements, vues 1D, 2D, 3D, traitement en parallèle D. Buskulic, Maubuisson 2001

149 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 D. Buskulic, Maubuisson 2001

150 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 natif Le fichier myClass.C est automatiquement compiléet lié !! D. Buskulic, Maubuisson 2001

151 La macro est automatiquement compilée et liée…
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 est automatiquement compilée et liée… D. Buskulic, Maubuisson 2001

152 V.5 Gestion des données V.5.3 Approche base de données dans ROOT
V. ROOT V.5 Gestion des données V.5.3 Approche base de données dans ROOT D. Buskulic, Maubuisson 2001

153 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…) D. Buskulic, Maubuisson 2001

154 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) Oracle ROOT Combine les deux technologies D. Buskulic, Maubuisson 2001

155 Catalogue Run/Fichiers Stockage d'événements Trees Fichiers ROOT
Oracle MySQL Etalonnages Stockage d'événements histograms Catalogue Run/Fichiers Trees Géométries D. Buskulic, Maubuisson 2001

156 V.6 Graphique : présentation des données 1, 2 et 3D
V. ROOT V.6 Graphique : présentation des données 1, 2 et 3D D. Buskulic, Maubuisson 2001

157 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 D. Buskulic, Maubuisson 2001

158 Tout objet dans le canvas peut être clické et édité
Options graphiques 1D Tout objet dans le canvas peut être clické et édité D. Buskulic, Maubuisson 2001

159 Plusieurs vues différentes du même objet
Options graphiques 2D Plusieurs vues différentes du même objet D. Buskulic, Maubuisson 2001

160 Options graphiques 2D Le nombre et le type des contours peut-être modifié avec la souris. Chaque contour est un objet D. Buskulic, Maubuisson 2001

161 Tous ces graphiques peuvent être tournés avec la souris
Options graphiques 2D Tous ces graphiques peuvent être tournés avec la souris D. Buskulic, Maubuisson 2001

162 Même image sur l'écran et sur une sortie Postscript
Options graphiques 2D Même image sur l'écran et sur une sortie Postscript D. Buskulic, Maubuisson 2001

163 V. ROOT V.7 Outils "physiques" D. Buskulic, Maubuisson 2001

164 Outils "physiques" Graphes Fonctions Histogrammes 1D, 2D, 3D
Minimisations D. Buskulic, Maubuisson 2001

165 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 D. Buskulic, Maubuisson 2001

166 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(); D. Buskulic, Maubuisson 2001

167 Les classes d'histogrammes
Pas dans PAW/Hbook 1-Dim 2-Dim 3-Dim D. Buskulic, Maubuisson 2001

168 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(); D. Buskulic, Maubuisson 2001

169 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(); D. Buskulic, Maubuisson 2001

170 "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 D. Buskulic, Maubuisson 2001

171 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); D. Buskulic, Maubuisson 2001

172 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 D. Buskulic, Maubuisson 2001

173 Projections Sont prévues : On peut ajuster ces projections par
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 D. Buskulic, Maubuisson 2001

174 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 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 D. Buskulic, Maubuisson 2001

175 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 D. Buskulic, Maubuisson 2001

176 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 D. Buskulic, Maubuisson 2001

177 Exemple d'ajustement Voir FittingDemo.C fitf.C Tourne FittingDemo.C
Macro non nommée fitf.C Macro nommée Tourne FittingDemo.C Plus d'infos: D. Buskulic, Maubuisson 2001

178 Combinaison de fonctions
y(E) = a1 + a2E + a3E AP ( / 2 )/( (E-)2 + (/2)2) background lorenzianPeak par[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 D. Buskulic, Maubuisson 2001

179 Fonctions associées TF1* myfunc = h->GetFunction("myfunc");
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"); D. Buskulic, Maubuisson 2001

180 V. ROOT V.8 Outils "techniques" D. Buskulic, Maubuisson 2001

181 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 D. Buskulic, Maubuisson 2001

182 V. ROOT V.9 Calcul parallèle D. Buskulic, Maubuisson 2001

183 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 D. Buskulic, Maubuisson 2001

184 ROOT/PROOF et les GRIDs
Sélection Paramètres TagDB CPU Procédure PROOF Local DB1 RDB Proc.C CPU DB2 Remote Proc.C DB3 CPU Proc.C DB4 Proc.C CPU Autant que possible, transférer la tâche vers les données et non l'inverse DB5 Proc.C CPU DB6 CPU D. Buskulic, Maubuisson 2001

185 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) D. Buskulic, Maubuisson 2001

186 Diagramme de traitement des données
Esclave 1 Maître Esclave N Tree->Draw() Tree->Draw() Initialisation Générateur de paquets Initialisation GetNextPacket() GetNextPacket() Traitement 0,100 100,100 Traitement GetNextPacket() GetNextPacket() Traitement 200,100 300,40 GetNextPacket() Traitement GetNextPacket() Traitement 340,100 440,50 Traitement GetNextPacket() GetNextPacket() Traitement 490,100 590,60 Traitement SendObject(histo) SendObject(histo) Attente commande Somme histogrammes Attente commande Affiche histogrammes D. Buskulic, Maubuisson 2001

187 Exemple d'une session PROOF
root [0] .! ls -l run846_tree.root -rw-r-r rdm cr 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 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 D. Buskulic, Maubuisson 2001

188 V.10 Documentation automatique
V. ROOT V.10 Documentation automatique D. Buskulic, Maubuisson 2001

189 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 D. Buskulic, Maubuisson 2001

190 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 Pages HTML Dictionnaire CINT et sources xxx.h, xxx.cc THtml D. Buskulic, Maubuisson 2001

191 Allez voir vous-même http://root.cern.ch/root/htmldoc/ClassIndex.html
D. Buskulic, Maubuisson 2001

192 V. ROOT V.11 Et ce n'est pas tout… D. Buskulic, Maubuisson 2001

193 Je ne vous ai pas tout dit…
Loin s'en faut… Plus de détails : Site web : Manuel ROOT Sur le Web : Doc, doc, doc Source et binaires pour une trentaine de combinaisons compilateurs/plateformes D. Buskulic, Maubuisson 2001