13-Novembre-2000L. Aphecetche L’analyse des DST  La base de tout: PHOOL Phenix Object Oriented Library  La méthode d’hier :  «

Présentation au sujet: "13-Novembre-2000L. Aphecetche L’analyse des DST  La base de tout: PHOOL Phenix Object Oriented Library  La méthode d’hier :  «"— Transcription de la présentation:

1 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)1 L’analyse des DST  La base de tout: PHOOL Phenix Object Oriented Library  La méthode d’hier :  « camDataCheck »  La méthode d’aujourd’hui :  pdst  Ce que demain nous réserve  lecture sélective  accès simplifié aux tables (seul type de données dans les DSTs pour l’instant)

2 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)2 PHOOL = données+modules  Des données organisées (en mémoire) sous forme d’arbre = ensemble de nœuds nommés PHCompositeNode PHDataNodePHIODataNode TOP EMCDST dEmcTempodEmcCluster dEmcCalibTower TransientPersistent

3 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)3 Les modules PHOOL  Un module agit sur tout ou partie d’un « node-tree », grâce à sa fonction event: event(PHCompositeNode*)  Les modules eux-mêmes peuvent être mis dans des nœuds…  La navigation dans les nœuds se fait grâce à des itérateurs : PHNodeIterator

4 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)4 PHOOL et la persistance  Persistance est gérée par des PHxxxManager :  PHNodeIOManager  pour lire/écrire les données dans les DSTs  PHRawOManager  pour écrire les événements dans les PRDF (Phenix Raw Data Format)  Types pouvant être persistants :  PHTable (et dérivés)  Event  TObject (mais Reset pose pb)

5 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)5 PHOOL  Un framework simple, facile à faire évoluer  2 formats de persistance pour l’instant:  PRDF (raw data)  ROOT (dst)  Une syntaxe un peu complexe ?  En cours d’ évolution...

6 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)6 Évolution PHOOL  Contribution SUBATECH:  lecture étiquetée des DSTs  lecture sélective des DSTs (qq tables seulement)  Revient à ajouter qq méthodes à 1 seule classe PHOOL: u PHNodeIOManager::readSpecific(int evt, char* objectName)  PHNodeIOManager::selectObjectToRead (char* objectName)  Déjà dans CVS et dans la release actuelle.

7 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)7 Lecture DST : camDataCheck  Méthode actuelle pour lire les DSTs.  Utilisées lors des nightly rebuilds et reconstruction pour Q&A de base.  C’est (juste) une macro ROOT.

8 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)8 camDataCheck  Un PHNodeIOManager recrée en mémoire un node- tree à partir de la DST (TTree Root)  Faire un boucle sur les événements: pour chaque evt :  accéder les différent nodes  accéder les tables/object contenus dans les nodes  remplir des histogrammes

9 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)9 camDataCheck : exemple PHCompositeNode* topNode =new PHCompositeNode("TOP"); PHCompositeNode* dstNode =new PHCompositeNode("DST"); topNode->addNode(dstNode); PHNodeIterator mainIter(topNode); PHNodeIOManager* dstIn = new PHNodeIOManager(« dstData.root »,PHReadOnly); // Recrée le node-tree en memoire à partir de la DST dstIn->read(dstNode); int i; for (i=0;i<nevent;i++) { if (i>0) dstIn->read(dstNode[,i]) ; // Trouver le nœud contenant la table PHIODataNode * OneNodeTable = (PHIODataNode *)mainIter.findFirst(« PHIODa taNode », »dEmcCalibTower »); // Trouver la table dans le nœud dEmcCalibTowerWrapper* dOneTable = (dEmcCalibTowerWrapper*)OneNodeTable->getData() ; } pdst/process_event à multiplier par le nombre de tables...

10 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)10 De camDataCheck à pdst  Il faut gérer la boucle sur les événements « à la main »  Solution : pdst (équivalent de pmonitor utilisé online) :  on se connecte à la DST  dfileopen (« dstData.root »)  on lance la boucle sur tous les événements (ou une partie)  drun (); ou drun (Nevents);  à chaque evt, la fonction utilisateur process_event(PHCompositeNode* topNode) est exécutée

11 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)11 Évolution (possible) de pdst  Problème actuel de pdst : l’ écriture de process_event reste (syntaxiquement) complexe (accès aux nœuds, puis aux tables : beaucoup de casting…)  Proposition faite à phenix- off : nouvelle classe PHDstHelper  ++ Son code peut être généré automatiquement à partir d’une DST

12 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)12 PHDstHelper process_event(PHCompositeNode* topNode) { PHDstHelper d(topNode) ; float zvertex = d.dEventHeader().get_zdcZVertex (0) ; }  Toute la machinerie des nœuds est maintenant cachée à l’utilisateur qui accède plus directement aux tables.  Principe accepté par M. Purschke (le responsable de pdst). Devrait apparaître bientôt dans CVS.

13 13-Novembre-2000L. Aphecetche (aphecetc@in2p3.fr)13 D’autres idées ?  Les DSTs contiennent un dRunHeader par événement…  Contribution à la base de données des runs (PHRED) ?  Autre chose que des PHTable dans les DSTs ?  Et si on rêvait d’une base de données des événements ?  Et d’une reconstruction entièrement compilée ?