Simulation, modélisation, traitement des données

D. Buskulic, Maubuisson 2001 1

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 ?

plexité des tâches

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

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

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

Segment

Vertex

Momentum

MassSquared

InterceptAtVertex

est un possèdeun

ss èd

•possèdeun

ss èd

•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

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 ?

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/

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

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 :

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

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

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

Services dePersistance

Données

Fonctions

Interface Utilisateur

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é

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++

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")

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

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

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

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

Remote

Procédure

Proc.C

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

Attentecommande

Esclave 1Tree->Draw()

s Initialisation

Traitement

Attentecommande

Esclave NMaîtreTree->Draw()

GetNextPacket()

SendObject(histo)SendObject(histo)

Sommehistogrammes

Affichehistogrammes

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

Simulation, modélisation, traitement des données

Documents

Transcript of Simulation, modélisation, traitement des données

Modélisation et simulation d’un système FACTS : UPFC

Modélisation et Simulation - Homepage de l'Université … de matières du cours Introduction à la modélisation et simulation Systèmes dynamiques Notions d’équilibre et stabilité

Analyse, modélisation et simulation de l'apparition de ...

Modélisation, caractérisation, simulation et ... · Revue des Energies Renouvelables Vol. 16 N°1 (2013) 143 – 157 143 Modélisation, caractérisation, simulation et interprétation

Économie de ressources Simulation La modélisation ...

Théorie de la Modélisation et de la Simulation ... · Plan 1 Modélisation et Simulation Déﬁnitions Paradigme et simulateur Classes de modèles 2 Formalismes de modélisation

Expérimentation, Modélisation, et Simulation en Psychologie

Modélisation et simulation de l'environnement dans les ...

Modélisation, simulation

Modélisation et simulation numérique de l’hydroformage

CHAPITRE VIII : Systèmes linéaires Modélisation & Simulation

Modélisation et simulation numérique de l'endommagement ...

VOLUME2 Asservissements modélisation et simulation

Modélisation et simulation d'une cellule Photovoltaïque ...

Modélisation et simulation des réseaux électriques

Thème Modélisation et Simulation d'un Système Photovoltaïque

Modélisation et simulation de la cavitation

Modélisation et simulation numérique par l'exemple

Étude expérimentale, modélisation et simulation numérique ...

MODÉLISATION ET SIMULATION (BIM)